Re: "could not open relation with OID" errors after promoting the standby to master - Mailing list pgsql-hackers

From Joachim Wieland
Subject Re: "could not open relation with OID" errors after promoting the standby to master
Date
Msg-id CACw0+10_HaceZsqeQP640uw+rVrw7cV+=GCJrX2VwqmTrDpAsQ@mail.gmail.com
Whole thread Raw
In response to Re: "could not open relation with OID" errors after promoting the standby to master  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: "could not open relation with OID" errors after promoting the standby to master
List pgsql-hackers
On Tue, May 22, 2012 at 9:50 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> Hmm.  I think that if you do it this way, the minimum recovery point
> won't be respected, which could leave you with a corrupted database.
> Now, if all the WAL files that you need are present in pg_xlog anyway,
> then they ought to get replayed anyway, but I think that if you are
> using restore_command (as opposed to streaming replication) we restore
> WAL segments under a different file name, which might cause this
> problem.

Uhm, maybe I add some more details, so you get a better idea of what I
did: The idea was to promote the standby to be the new master. There
was streaming replication active but at some time I had to take the
master down. IIRC from the log I saw that after the master went down,
the standby continued recovering from a bunch of archived log files
(via recovery_command), I had suspected that either the standby was
lagging behind a bit or that the master archived them during shutdown.
When the standby didn't have anything else left to recover from
(saying both "xlog file foo doesn't exist" and "cannot connect to
master"), I deleted recovery.conf on the standby and restarted it.

I wouldn't have assumed any corruption was possible given that I did
clean shutdowns on both sides...


pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Interrupting long external library calls
Next
From: Sandro Santilli
Date:
Subject: Re: Interrupting long external library calls