To: Simon Riggs <simon@2ndQuadrant.com>
cc: List pgsql-patches <pgsql-patches@postgresql.org>,
	pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: [PATCHES] Infrastructure changes for recovery 
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>
Comments: In-reply-to Simon Riggs <simon@2ndQuadrant.com>
	message dated "Mon, 29 Sep 2008 01:54:19 +0100"
Date: Sun, 28 Sep 2008 21:16:01 -0400
Message-ID: <22856.1222650961@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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