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.
(let's do the startup checkpoint for now, as discussed elsewhere in this
thread)
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com