On 13.02.2013 21:30, Tom Lane wrote:
Heikki Linnakangas<hlinnakan...@vmware.com> writes:
On 13.02.2013 21:21, Tom Lane wrote:
It would only be broken if someone interrupted a crash recovery
mid-flight and tried to establish a recovery stop point before the end
of WAL, no? Why don't we just forbid that case? This would either be
the same as, or a small extension of, the pg_control state vs existence
of recovery.conf error check that was just discussed.
The problem is when you interrupt archive recovery (kill -9), and
restart. After restart, the system needs to know how far the WAL was
replayed before the crash, because it must not open for hot standby
queries, or allow the database to be started up in master-mode, until
it's replayed the WAL up to that same point again.
Well, archive recovery is a different scenario --- Simon was questioning
whether we need a minRecoveryPoint mechanism in crash recovery, or at
least that's what I thought he asked.
Ah, ok. The short answer to that is "no", because in crash recovery, we
just replay the WAL all the way to the end. I thought he was questioning
updating the control file at every XLogFlush() during archive recovery.
The answer to that is that it's not so bad, because XLogFlush() is
called so infrequently during recovery.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
