Reduce severity of 'XLogFlush: request is not satisfied' error condition,

per my proposal of a couple days ago.  This will eliminate the unable-
to-restart-database class of problem that we have seen reported half a
dozen times with 7.1.*.

diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c
index 46e3470ae384e6d514be676da39b27560f4b1694..a8e5e43a027e7ac756728ce90dc223659b732e17 100644 (file)
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@ -7,7 +7,7 @@
  * Portions Copyright (c) 1996-2001, PostgreSQL Global Development Group
  * Portions Copyright (c) 1994, Regents of the University of California
  *
- * $Header: /cvsroot/pgsql/src/backend/access/transam/xlog.c,v 1.85 2001/12/28 18:16:41 tgl Exp $
+ * $Header: /cvsroot/pgsql/src/backend/access/transam/xlog.c,v 1.86 2002/01/14 17:55:57 tgl Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -1262,15 +1262,40 @@ XLogFlush(XLogRecPtr record)
                        WriteRqst.Write = WriteRqstPtr;
                        WriteRqst.Flush = record;
                        XLogWrite(WriteRqst);
-                       if (XLByteLT(LogwrtResult.Flush, record))
-                               elog(STOP, "XLogFlush: request %X/%X is not satisfied --- flushed only to %X/%X",
-                                        record.xlogid, record.xrecoff,
-                                 LogwrtResult.Flush.xlogid, LogwrtResult.Flush.xrecoff);
                }
                LWLockRelease(WALWriteLock);
        }
 
        END_CRIT_SECTION();
+
+       /*
+        * If we still haven't flushed to the request point then we have a
+        * problem; most likely, the requested flush point is past end of XLOG.
+        * This has been seen to occur when a disk page has a corrupted LSN.
+        *
+        * Formerly we treated this as a STOP condition, but that hurts the
+        * system's robustness rather than helping it: we do not want to take
+        * down the whole system due to corruption on one data page.  In
+        * particular, if the bad page is encountered again during recovery then
+        * we would be unable to restart the database at all!  (This scenario
+        * has actually happened in the field several times with 7.1 releases.
+        * Note that we cannot get here while InRedo is true, but if the bad
+        * page is brought in and marked dirty during recovery then
+        * CreateCheckpoint will try to flush it at the end of recovery.)
+        *
+        * The current approach is to ERROR under normal conditions, but only
+        * NOTICE during recovery, so that the system can be brought up even if
+        * there's a corrupt LSN.  Note that for calls from xact.c, the ERROR
+        * will be promoted to STOP since xact.c calls this routine inside a
+        * critical section.  However, calls from bufmgr.c are not within
+        * critical sections and so we will not force a restart for a bad LSN
+        * on a data page.
+        */
+       if (XLByteLT(LogwrtResult.Flush, record))
+               elog(InRecovery ? NOTICE : ERROR,
+                        "XLogFlush: request %X/%X is not satisfied --- flushed only to %X/%X",
+                        record.xlogid, record.xrecoff,
+                        LogwrtResult.Flush.xlogid, LogwrtResult.Flush.xrecoff);
 }
 
 /*