Subject: Re: Infrastructure changes for recovery
From: Simon Riggs <simon@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
In-Reply-To: <29481.1218120486@sss.pgh.pa.us>
References: <1218109459.4549.423.camel@ebony.2ndQuadrant>
	<29481.1218120486@sss.pgh.pa.us>
Content-Type: text/plain
Date: Thu, 07 Aug 2008 16:28:20 +0100
Message-Id: <1218122900.4549.538.camel@ebony.2ndQuadrant>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit


On Thu, 2008-08-07 at 10:48 -0400, Tom Lane wrote:
> Simon Riggs <simon@2ndquadrant.com> writes:
> > I propose to
> > * have startup process signal postmaster when it starts Redo phase (if
> > it starts it)
> 
> Doesn't seem like "starts recovery" is the point at which you can start
> letting clients into the DB.  What you want is to reach a point at which
> you're sure that the DB is internally consistent, though perhaps not
> fully synced with the master.  In a PITR recovery scenario this would
> correspond to reaching the minimum safe stop point.  In true crash
> recovery I don't think you can let people in till you're done.

Ack to both, no worries: just worded it a little too loosely.

For crash recovery we could let them in earlier, but I think its going
to recover faster if we don't. So, yes, only during archive recovery and
therefore only from min safe stopping point. That will mean bgwriter is
only active during archive recovery, but that's not important, since we
(almost) never perform restartpoints during crash recovery.

For other background I should also mention that this architecture
proposal is different from Florian's SoC proposals, which had a separate
recovery process to perform the work after the min safe stopping point. 

-- 
 Simon Riggs           www.2ndQuadrant.com
 PostgreSQL Training, Services and Support