On Wed, Mar 19, 2014 at 5:28 PM, Kyotaro HORIGUCHI
<horiguchi.kyot...@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.


Fujii Masao

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to