On 13.02.2013 21:30, Tom Lane wrote:
> Heikki Linnakangas<hlinnakangas@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