Subject: Re: [PATCHES] Infrastructure changes for recovery
From: Simon Riggs <simon@2ndQuadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: List pgsql-patches <pgsql-patches@postgresql.org>,
	pgsql-hackers <pgsql-hackers@postgresql.org>
In-Reply-To: <16992.1221743196@sss.pgh.pa.us>
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>
Content-Type: text/plain
Date: Thu, 18 Sep 2008 14:50:47 +0100
Message-Id: <1221745847.3913.2408.camel@ebony.2ndQuadrant>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit


On Thu, 2008-09-18 at 09:06 -0400, Tom Lane wrote:
> Simon Riggs <simon@2ndQuadrant.com> writes:
> > Having some trouble trying to get a clean state change from recovery to
> > normal mode.
> 
> > Startup needs to be able to write WAL at the end of recovery so it can
> > write a ShutdownCheckpoint, yet must not be allowed to write WAL before
> > that. Other services are still not fully up yet. So every other process
> > apart from Startup musn't write WAL until Startup has fully completed
> > its actions, which is sometime later.
> > ...
> > We *might* solve this by making the final checkpoint that Startup writes
> > into an online checkpoint.
> 
> Do we really need a checkpoint there at all?  I can't recall right now
> if there was a good reason why Vadim made it do that.  I have a feeling
> that it might have had to do with an assumption that the recovery
> environment was completely distinct from live environment; which is a
> statement that's certainly not going to be true in a query-answering
> slave.

Hmm, a question I hadn't considered.

We definitely don't want to do PreallocXlogFiles().

"Timelines only change at shutdown checkpoints". But its just as easy to
write a short timeline change record rather than the checkpoint itself,
so we can sort that out.

It should be sufficient to request bgwriter to perform an immediate
checkpoint, rather than have startup process perform it. That way
startup can exit and we can change to normal processing faster.

If we crash before the next checkpoint then we would revert to archive
recovery or crash recovery. The last restartpoint might well be
somewhere else. In streaming mode we would presumably have that data
locally, so not really a problem. But we musn't mark control file in
production yet, but we can do so following the next checkpoint.

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