From 463f151a23242c531890589db3692077aadb05ca Mon Sep 17 00:00:00 2001 From: Simon Riggs Date: Thu, 13 May 2010 11:39:30 +0000 Subject: [PATCH] Ensure that top level aborts call XLogSetAsyncCommit(). Not doing so simply leads to data waiting in wal_buffers which then causes later commits to potentially do emergency writes and for all forms of replication to be potentially delayed without need or benefit. Issue pointed out exactly by Fujii Masao, following bug report by Robert Haas on a separate though related topic. --- src/backend/access/transam/xact.c | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/src/backend/access/transam/xact.c b/src/backend/access/transam/xact.c index 91fbbd0be6..8f2a3ed5e4 100644 --- a/src/backend/access/transam/xact.c +++ b/src/backend/access/transam/xact.c @@ -10,7 +10,7 @@ * * * IDENTIFICATION - * $PostgreSQL: pgsql/src/backend/access/transam/xact.c,v 1.290 2010/05/13 11:15:38 sriggs Exp $ + * $PostgreSQL: pgsql/src/backend/access/transam/xact.c,v 1.291 2010/05/13 11:39:30 sriggs Exp $ * *------------------------------------------------------------------------- */ @@ -1347,6 +1347,18 @@ RecordTransactionAbort(bool isSubXact) (void) XLogInsert(RM_XACT_ID, XLOG_XACT_ABORT, rdata); + /* + * Report the latest async abort LSN, so that the WAL writer knows to + * flush this abort. There's nothing to be gained by delaying this, + * since WALWriter may as well do this when it can. This is important + * with streaming replication because if we don't flush WAL regularly + * we will find that large aborts leave us with a long backlog for + * when commits occur after the abort, increasing our window of data + * loss should problems occur at that point. + */ + if (!isSubXact) + XLogSetAsyncCommitLSN(XactLastRecEnd); + /* * Mark the transaction aborted in clog. This is not absolutely necessary * but we may as well do it while we are here; also, in the subxact case