Re: [PATCHES] Infrastructure changes for recovery - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: [PATCHES] Infrastructure changes for recovery
Date
Msg-id 1221745847.3913.2408.camel@ebony.2ndQuadrant
Whole thread Raw
In response to Re: [PATCHES] Infrastructure changes for recovery  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [PATCHES] Infrastructure changes for recovery
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: "Greg Sabino Mullane"
Date:
Subject: Re: Do we really need a 7.4.22 release now?
Next
From: Tom Lane
Date:
Subject: Re: Adding new flags to XLogRecord