From: Simon Riggs <simon@2ndQuadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: List pgsql-patches <pgsql-patches@postgresql.org>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: [PATCHES] Infrastructure changes for recovery
Date: Fri, 26 Sep 2008 12:42:06 +0100
Message-ID: <1222429326.4445.945.camel@ebony.2ndQuadrant> (raw)
In-Reply-To: <1222424415.4445.917.camel@ebony.2ndQuadrant>
References: <1218109459.4549.423.camel@ebony.2ndQuadrant>
<1220213074.4371.173.camel@ebony.2ndQuadrant>
<1905.1220895241@sss.pgh.pa.us>
<1221080797.3913.768.camel@ebony.2ndQuadrant>
<15776.1221594318@sss.pgh.pa.us>
<1221725145.3913.2315.camel@ebony.2ndQuadrant>
<16992.1221743196@sss.pgh.pa.us>
<1221745847.3913.2408.camel@ebony.2ndQuadrant>
<18549.1221746983@sss.pgh.pa.us>
<1222121161.4445.248.camel@ebony.2ndQuadrant>
<1222184541.4445.400.camel@ebony.2ndQuadrant>
<28973.1222381719@sss.pgh.pa.us>
<1222424415.4445.917.camel@ebony.2ndQuadrant>
On Fri, 2008-09-26 at 11:20 +0100, Simon Riggs wrote:
> > After reading this for awhile, I realized that there is a rather
> > fundamental problem with it: it switches into "consistent recovery"
> > mode as soon as it's read WAL beyond ControlFile->minRecoveryPoint.
> > In a crash recovery situation that typically is before the last
> > checkpoint (if indeed it's not still zero), and what that means is
> > that this patch will activate the bgwriter and start letting in
> > backends instantaneously after a crash, long before we can have any
> > certainty that the DB state really is consistent.
> >
> > In a normal crash recovery situation this would be easily fixed by
> > simply not letting it go to "consistent recovery" state at all, but
> > what about recovery from a restartpoint? We don't want a slave that's
> > crashed once to never let backends in again. But I don't see how to
> > determine that we're far enough past the restartpoint to be consistent
> > again. In crash recovery we assume (without proof ;-)) that we're
> > consistent once we reach the end of valid-looking WAL, but that rule
> > doesn't help for a slave that's following a continuing WAL sequence.
> >
> > Perhaps something could be done based on noting when we have to pull in
> > a WAL segment from the recovery_command, but it sounds like a pretty
> > fragile assumption.
>
> Seems like we just say we only signal the postmaster if
> InArchiveRecovery. Archive recovery from a restartpoint is still archive
> recovery, so this shouldn't be a problem in the way you mention. The
> presence of recovery.conf overrides all other cases.
Anticipating your possible reponses, I would add this also:
There has long been an annoying hole in the PITR scheme which is the
support of recovery using a crashed database. That is there to support
split mirror snapshots, but it creates a loophole where we don't know
the min recovery location, circumventing the care we (you!) took to put
stop/start backup in place.
I think we need to add a parameter to recovery.conf that people can use
to specify a minRecoveryPoint iff there in no backup label file. They
can work out what this should be by following this procedure, which we
should document:
* split mirror, so you have offline copy of crashed database
* copy database away to backup
* go to running database and run pg_current_xlog_insert_location()
* use the value to specify recovery_min_location
If they don't specify this, then bgwriter will not start and you cannot
run in Hot Standby mode. Their choice, so we need not worry then about
the loophole any more.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
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: simon@2ndQuadrant.com, tgl@sss.pgh.pa.us, pgsql-hackers@postgresql.org
Subject: Re: [PATCHES] Infrastructure changes for recovery
In-Reply-To: <1222429326.4445.945.camel@ebony.2ndQuadrant>
* 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