On Wed, Mar 19, 2014 at 7:57 PM, Heikki Linnakangas <hlinnakan...@vmware.com> wrote: > On 03/19/2014 10:28 AM, Kyotaro HORIGUCHI wrote: >> >> The*problematic* operation sequence I saw was performed by >> >> pgsql-RA/Pacemaker. It stops a server already with immediate mode >> and starts the Master as a Standby at first, then >> promote. Focusing on this situation, there would be reasonable to >> reset backup positions. > > > Well, that's scary. I would suggest doing a fast shutdown instead. But if > you really want to do an immediate shutdown, you should delete the > backup_label file after the shutdown > > When restarting after immediate shutdown and a backup_label file is present, > the system doesn't know if the system crashed during a backup, and it needs > to perform crash recovery, or if you're trying restore from a backup. It > makes a compromise, and starts recovery from the checkpoint given in the > backup_label, as if it was restoring from a backup, but if it doesn't see a > backup-end WAL record, it just starts up anyway (which would be wrong if you > are indeed restoring from a backup). But if you create a recovery.conf file, > that indicates that you are definitely restoring from a backup, so it's more > strict and insists that the backup-end record must be replayed. > > >> 9.4 canceles backup mode even on >> immediate shutdown so the operation causes no problem, but 9.3 >> and before are doesn't. > > > Hmm, I don't think we've changed that behavior in 9.4.
ISTM 82233ce7ea42d6ba519aaec63008aff49da6c7af changed immdiate shutdown that way. Regards, -- Fujii Masao -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
