Message-ID: <49218594.5040000@enterprisedb.com>
Date: Mon, 17 Nov 2008 16:54:12 +0200
Organization: EnterpriseDB
User-Agent: Mozilla-Thunderbird 2.0.0.16 (X11/20080724)
MIME-Version: 1.0
To: Simon Riggs <simon@2ndQuadrant.com>
CC: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: [PATCHES] Infrastructure changes for recovery (v8)
References: <1222815151.4445.1397.camel@ebony.2ndQuadrant>	
	<48EC9CC5.6060803@enterprisedb.com>	
	<1223468660.4747.294.camel@ebony.2ndQuadrant>
	<1223472898.4747.310.camel@ebony.2ndQuadrant>
In-Reply-To: <1223472898.4747.310.camel@ebony.2ndQuadrant>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
From: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>

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