From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: "could not open relation with OID" errors after promoting the standby to master |
Date: | 2012-05-24 16:46:13 |
Message-ID: | 201205241846.13738.andres@anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thursday, May 24, 2012 06:35:06 PM Heikki Linnakangas wrote:
> On 24.05.2012 18:16, Robert Haas wrote:
> > On Thu, May 24, 2012 at 10:13 AM, Joachim Wieland<joe(at)mcknight(dot)de> wrote:
> >> I wouldn't have assumed any corruption was possible given that I did
> >> clean shutdowns on both sides...
> >
> > The thing that's worrying me is that there's not really any such thing
> > as a "clean" shutdown on a standby. When you shut down the master, it
> > checkpoints. When you shut down the standby, it can't checkpoint, so
> > I think it's still going to enter recovery at startup. It'd be
> > interesting to know where that recovery began and ended as compared
> > with the minimum recovery point just before the shutdown.
>
> Perhaps we should introduce the concept of a clean standby shutdown. We
> can't write a checkpoint record, but we could write the same information
> somewhere else. Like in the control file. At startup, we'd see that we
> did a clean shutdown at WAL point X/X, and start up without having to
> read through all the WAL from the last master checkpoint.
The control file currently is not a very good match because of the current
requirement of staying below 512 bytes. If we would include the list of
running xacts that wouldn't be enough.
I wondered before if there is more to do to fix that then to do the atomic
write();fsync();rename();fsync(); dance. I don't see a problem with the cost
of that personally...
Andres
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2012-05-24 17:02:27 | Re: pg_basebackup -x stream from the standby gets stuck |
Previous Message | Kohei KaiGai | 2012-05-24 16:42:30 | Re: [RFC] Interface of Row Level Security |