From: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | masao(dot)fujii(at)gmail(dot)com |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Archive recovery won't be completed on some situation. |
Date: | 2014-03-17 00:15:26 |
Message-ID: | 20140317.091526.221308053.horiguchi.kyotaro@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Thank you for good suggestion.
> > What the mess is once entering this situation, I could find no
> > formal operation to exit from it.
>
> Though this is formal way, you can exit from that situation by
>
> (1) Remove recovery.conf and start the server with crash recovery
> (2) Execute pg_start_backup() after crash recovery ends
> (3) Copy backup_label to somewhere
> (4) Execute pg_stop_backup() and shutdown the server
> (5) Copy backup_label back to $PGDATA
> (6) Create recovery.conf and start the server with archive recovery
It will do. And pg_resetxlog was the first thing I checked out
for reseting backupStartPoint.
> 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.
It is in far better proportion than recovery.conf option:), since
it is already warned to be dangerous as its nature. Anyway I'll
make sure the situation under the trouble fist.
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | Kouhei Kaigai | 2014-03-17 00:29:29 | Re: Custom Scan APIs (Re: Custom Plan node) |
Previous Message | Greg Stark | 2014-03-16 19:32:04 | Re: First-draft release notes for next week's releases |