Re: [PATCHES] Infrastructure changes for recovery (v8)

This comment in XLogFlush is no longer accurate:

> * The current approach is to ERROR under normal conditions, but only
> * WARNING 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 PANIC 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(ERROR,
> "xlog flush request %X/%X is not satisfied --- flushed only to %X/%X",
> record.xlogid, record.xrecoff,
> LogwrtResult.Flush.xlogid, LogwrtResult.Flush.xrecoff);

Because of this hunk:

> ***************
> *** 1822,1828 **** XLogFlush(XLogRecPtr record)
> * and so we will not force a restart for a bad LSN on a data page.
> */
> if (XLByteLT(LogwrtResult.Flush, record))
> ! elog(InRecovery ? WARNING : ERROR,
> "xlog flush request %X/%X is not satisfied --- flushed only to %X/%X",
> record.xlogid, record.xrecoff,
> LogwrtResult.Flush.xlogid, LogwrtResult.Flush.xrecoff);
> --- 1874,1880 ----
> * and so we will not force a restart for a bad LSN on a data page.
> */
> if (XLByteLT(LogwrtResult.Flush, record))
> ! elog(ERROR,
> "xlog flush request %X/%X is not satisfied --- flushed only to %X/%X",
> record.xlogid, record.xrecoff,
> LogwrtResult.Flush.xlogid, LogwrtResult.Flush.xrecoff);

I'm not sure what the most robust behavior would be.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com