From: Tom Lane <tgl@sss.pgh.pa.us>
To: Simon Riggs <simon@2ndQuadrant.com>
Cc: List pgsql-patches <pgsql-patches@postgresql.org>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: [PATCHES] Infrastructure changes for recovery
Date: Sun, 28 Sep 2008 21:16:01 -0400
Message-ID: <22856.1222650961@sss.pgh.pa.us> (raw)
In-Reply-To: <1222649659.4445.1061.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>
<9794.1222624945@sss.pgh.pa.us>
<1222649659.4445.1061.camel@ebony.2ndQuadrant>
Simon Riggs <simon@2ndQuadrant.com> writes:
>> It does nothing AFAICS for the
>> problem that when restarting archive recovery from a restartpoint,
>> it's not clear when it is safe to start letting in backends. You need
>> to get past the highest LSN that has made it out to disk, and there is
>> no good way to know what that is.
> AFAICS when we set minRecoveryLoc we *never* unset it. It's recorded in
> the controlfile, so whenever we restart we can see that it has been set
> previously and now we are beyond it.
Right ...
> So if we crash during recovery and
> then restart *after* we reached minRecoveryLoc then we resume in safe
> mode almost immediately.
Wrong.
What minRecoveryLoc is is an upper bound for the LSNs that might be
on-disk in the filesystem backup that an archive recovery starts from.
(Defined as such, it never changes during a restartpoint crash/restart.)
Once you pass that, the on-disk state as modified by any dirty buffers
inside the recovery process represents a consistent database state.
However, the on-disk state alone is not guaranteed consistent. As you
flush some (not all) of your shared buffers you enter other
not-certainly-consistent on-disk states. If we crash in such a state,
we know how to use the last restartpoint plus WAL replay to recover to
another state in which disk + dirty buffers are consistent. However,
we reach such a state only when we have read WAL to beyond the highest
LSN that has reached disk --- and in recovery mode there is no clean
way to determine what that was.
Perhaps a solution is to make XLogFLush not be a no-op in recovery mode,
but have it scribble a highest-LSN somewhere on stable storage (maybe
scribble on pg_control itself, or maybe better someplace else). I'm
not totally sure about that. But I am sure that doing nothing will
be unreliable.
regards, tom lane
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: tgl@sss.pgh.pa.us, simon@2ndQuadrant.com, pgsql-hackers@postgresql.org
Subject: Re: [PATCHES] Infrastructure changes for recovery
In-Reply-To: <22856.1222650961@sss.pgh.pa.us>
* 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