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

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

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.

- Heikki

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2014-03-17 14:25:42 Re: Patch: show relation and tuple infos of a lock to acquire
Previous Message Tom Lane 2014-03-17 13:47:43 Re: pg_dump without explicit table locking