Re: 9.2.3 crashes during archive recovery

From: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Simon Riggs <simon(at)2ndQuadrant(dot)com>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: 9.2.3 crashes during archive recovery
Date: 2013-02-13 19:27:06
Message-ID: 511BE90A.605@vmware.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 13.02.2013 21:21, Tom Lane wrote:
> Heikki Linnakangas<hlinnakangas(at)vmware(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2013-02-13 19:30:10 Re: 9.2.3 crashes during archive recovery
Previous Message Tom Lane 2013-02-13 19:21:42 Re: 9.2.3 crashes during archive recovery