Add C comment about why synchronous_commit=off behavior can lose

committed transactions in a postmaster crash.

diff --git a/src/backend/access/transam/xact.c b/src/backend/access/transam/xact.c
index 8f2a3ed5e4fa2759a3ae5769e7613174ce32d07c..d97b75ab96ee2c61846220af3746aafa62cf6fa0 100644 (file)
--- 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.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)
        {
                /*
-                * Synchronous commit case.
+                * Synchronous commit case:
                 *
                 * Sleep before flush! So we can flush more than one commit records
                 * per single fsync.  (The idea is some other backend may do the
@@ -1054,7 +1054,12 @@ RecordTransactionCommit(void)
        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
                 * flush this commit.