Add C comment about why synchronous_commit=off behavior can lose

committed transactions in a postmaster crash.
This commit is contained in:
Bruce Momjian 2010-06-29 18:44:58 +00:00
parent 89474cc321
commit b57ddccf05

View File

@ -10,7 +10,7 @@
* *
* *
* IDENTIFICATION * IDENTIFICATION
* $PostgreSQL: pgsql/src/backend/access/transam/xact.c,v 1.291 2010/05/13 11:39:30 sriggs Exp $ * $PostgreSQL: pgsql/src/backend/access/transam/xact.c,v 1.292 2010/06/29 18:44:58 momjian Exp $
* *
*------------------------------------------------------------------------- *-------------------------------------------------------------------------
*/ */
@ -1028,7 +1028,7 @@ RecordTransactionCommit(void)
if (XactSyncCommit || forceSyncCommit || haveNonTemp) if (XactSyncCommit || forceSyncCommit || haveNonTemp)
{ {
/* /*
* Synchronous commit case. * Synchronous commit case:
* *
* Sleep before flush! So we can flush more than one commit records * Sleep before flush! So we can flush more than one commit records
* per single fsync. (The idea is some other backend may do the * per single fsync. (The idea is some other backend may do the
@ -1054,7 +1054,12 @@ RecordTransactionCommit(void)
else else
{ {
/* /*
* Asynchronous commit case. * Asynchronous commit case:
*
* This enables possible committed transaction loss in the case of a
* postmaster crash because WAL buffers are left unwritten.
* Ideally we could issue the WAL write without the fsync, but
* some wal_sync_methods do not allow separate write/fsync.
* *
* Report the latest async commit LSN, so that the WAL writer knows to * Report the latest async commit LSN, so that the WAL writer knows to
* flush this commit. * flush this commit.