On 13.02.2013 21:21, Tom Lane wrote:
> Heikki Linnakangas<hlinnakangas@vmware.com> writes:
>> Well, no-one's complained about the performance. From a robustness point
>> of view, it might be good to keep the minRecoveryPoint value in a
>> separate file, for example, to avoid rewriting the control file that
>> often. Then again, why fix it when it's not broken.
>
> 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.
- Heikki