rm_cleanup functions need to be allowed to write WAL entries. This oversight

appears to explain the recent reports of "PANIC: cannot make new WAL entries
during recovery".

diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c
index 5990bae8b84463c866a5d182e1171110d7b5578d..f2fb9ed8f568174347955d8a7b9927eefead42f9 100644 (file)
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@ -7,7 +7,7 @@
  * Portions Copyright (c) 1996-2009, PostgreSQL Global Development Group
  * Portions Copyright (c) 1994, Regents of the University of California
  *
- * $PostgreSQL: pgsql/src/backend/access/transam/xlog.c,v 1.345 2009/06/26 20:29:04 tgl Exp $
+ * $PostgreSQL: pgsql/src/backend/access/transam/xlog.c,v 1.346 2009/08/07 19:29:49 tgl Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -463,6 +463,7 @@ static void readRecoveryCommandFile(void);
 static void exitArchiveRecovery(TimeLineID endTLI,
                    uint32 endLogId, uint32 endLogSeg);
 static bool recoveryStopsHere(XLogRecord *record, bool *includeThis);
+static void LocalSetXLogInsertAllowed(void);
 static void CheckPointGuts(XLogRecPtr checkPointRedo, int flags);
 
 static bool XLogCheckBuffer(XLogRecData *rdata, bool doPageWrites,
@@ -5758,6 +5759,13 @@ StartupXLOG(void)
    {
        int         rmid;
 
+       /*
+        * Resource managers might need to write WAL records, eg, to record
+        * index cleanup actions.  So temporarily enable XLogInsertAllowed in
+        * this process only.
+        */
+       LocalSetXLogInsertAllowed();
+
        /*
         * Allow resource managers to do any required cleanup.
         */
@@ -5767,6 +5775,9 @@ StartupXLOG(void)
                RmgrTable[rmid].rm_cleanup();
        }
 
+       /* Disallow XLogInsert again */
+       LocalXLogInsertAllowed = -1;
+
        /*
         * Check to see if the XLOG sequence contained any unresolved
         * references to uninitialized pages.