Re: Archive recovery won't be completed on some situation. - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: Archive recovery won't be completed on some situation.
Date
Msg-id CAHGQGwH-1AvtG9yMWLf_eopcrB4Vp-BptE7cMb3pXCycyKahYg@mail.gmail.com
Whole thread Raw
In response to Re: Archive recovery won't be completed on some situation.  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Responses Re: Archive recovery won't be completed on some situation.  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
List pgsql-hackers
On Wed, Mar 19, 2014 at 5:28 PM, Kyotaro HORIGUCHI
<horiguchi.kyotaro@lab.ntt.co.jp> wrote:
> Hello, thank you for suggestions.
>
> The *problematic* operation sequence I saw was performed by
> pgsql-RA/Pacemaker. It stops a server already with immediate mode
> and starts the Master as a Standby at first, then
> promote. Focusing on this situation, there would be reasonable to
> reset backup positions. 9.4 canceles backup mode even on
> immediate shutdown so the operation causes no problem, but 9.3
> and before are doesn't. Finally, needed amendments per versions
> are
>
> 9.4: Nothing more is needed (but resetting backup mode by
>      resetxlog is acceptable)
>
> 9.3: Can be recovered without resetting backup positions in
>      controlfile.  (but smarter with it)
>
> 9.2: Same to 9.3
>
> 9.1: Cannot be recoverd without directly resetting backup
>      position in controlfile.  Resetting feature is needed.
>
>
> At Mon, 17 Mar 2014 15:59:09 +0200, Heikki Linnakangas wrote
>> On 03/15/2014 05:59 PM, Fujii Masao wrote:
>> > What about adding new option into pg_resetxlog so that we can
>> > reset the pg_control's backup start location? Even after we've
>> > accidentally entered into the situation that you described, we can
>> > exit from that by resetting the backup start location in pg_control.
>> > Also this option seems helpful to salvage the data as a last resort
>> > from the corrupted backup.
>>
>> Yeah, seems reasonable. After you run pg_resetxlog, there's no hope
>> that the backup end record would arrive any time later. And if it
>> does, it won't really do much good after you've reset the WAL.
>>
>> We probably should just clear out the backup start/stop location
>> always when you run pg_resetxlog. Your database is potentially broken
>> if you reset the WAL before reaching consistency, but if forcibly do
>> that with "pg_resetxlog -f", you've been warned.
>
> Agreed. Attached patches do that and I could "recover" the
> database state with following steps,

Adding new option looks like new feature rather than bug fix.
I'm afraid that the backpatch of such a change to 9.3 or before
is not acceptable.

Regards,

-- 
Fujii Masao



pgsql-hackers by date:

Previous
From: Petr Jelinek
Date:
Subject: Re: Review: plpgsql.extra_warnings, plpgsql.extra_errors
Next
From: Heikki Linnakangas
Date:
Subject: Re: Archive recovery won't be completed on some situation.