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
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 |