From: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
To: Simon Riggs <simon@2ndQuadrant.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: [PATCHES] Infrastructure changes for recovery (v8)
Date: Mon, 17 Nov 2008 16:54:12 +0200
Message-ID: <49218594.5040000@enterprisedb.com> (raw)
In-Reply-To: <1223472898.4747.310.camel@ebony.2ndQuadrant>
References: <1222815151.4445.1397.camel@ebony.2ndQuadrant>
<48EC9CC5.6060803@enterprisedb.com>
<1223468660.4747.294.camel@ebony.2ndQuadrant>
<1223472898.4747.310.camel@ebony.2ndQuadrant>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-patches@postgresql.org
Cc: heikki.linnakangas@enterprisedb.com, simon@2ndQuadrant.com, pgsql-hackers@postgresql.org
Subject: Re: [PATCHES] Infrastructure changes for recovery (v8)
In-Reply-To: <49218594.5040000@enterprisedb.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox