Re: Archive recovery won't be completed on some situation.

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
Cc: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Archive recovery won't be completed on some situation.
Date: 2014-03-19 10:34:10
Message-ID: CAHGQGwH-1AvtG9yMWLf_eopcrB4Vp-BptE7cMb3pXCycyKahYg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Mar 19, 2014 at 5:28 PM, Kyotaro HORIGUCHI
<horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2014-03-19 10:57:02 Re: Archive recovery won't be completed on some situation.
Previous Message Petr Jelinek 2014-03-19 10:28:40 Re: Review: plpgsql.extra_warnings, plpgsql.extra_errors