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

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

In response to

Responses

Browse pgsql-hackers by date

  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