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