On Thu, 2009-02-05 at 10:07 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Thu, 2009-02-05 at 09:28 +0200, Heikki Linnakangas wrote:
> >> Simon Riggs wrote:
> >>> I would suggest that at end of recovery we write the last LSN to the
> >>> control file, so if we crash recover then we will always end archive
> >>> recovery at the same place again should we re-enter it. So we would have
> >>> a recovery_target_lsn that overrides recovery_target_xid etc..
> >> Hmm, we don't actually want to end recovery at the same point again: if
> >> there's some updates right after the database came up, but before the
> >> first checkpoint and crash, those actions need to be replayed too.
> >
> > I think we do need to. Crash recovery is supposed to return us to the
> > same state. Where we ended ArchiveRecovery is part of that state.
> >
> > It isn't for crash recovery to decide that it saw a few more
> > transactions and decided to apply them anyway. The user may have
> > specifically ended recovery to avoid those additional changes from
> > taking place.
>
> Those additional changes were made in the standby, after ending
> recovery. So the sequence of events is:
>
> 1. Standby performs archive recovery
> 2. End of archive (or stop point) reached. Open for connections,
> read-write. Request an online checkpoint. Online checkpoint begins.
> 3. A user connects, and does "INSERT INTO foo VALUES (123)". Commits,
> commit returns.
> 4. "pg_ctl stop -m immediate". The checkpoint started in step 2 hasn't
> finished yet
> 5. Restart the server.
>
> The server will now re-enter archive recovery. But this time, we want to
> replay the INSERT too.
I agree with this, so let me restate both comments together.
When the server starts it begins a new timeline.
When recovering we must switch to that timeline at the same point we did
previously when we ended archive recovery. We currently don't record
when that is and we need to.
Yes, we must also replay the records in the new timeline once we have
switched to it, as you say. But we must not replay any further in the
older timeline(s).
-- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
