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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
