> 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

"We"'d also said them the former thing on several occations. They
answered that they hate shutdown checkpoint to take long time
before shutdown is completed. The latter one has not come on my
mind and seems promising. Thank you for the suggestion.

> 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.

Now pmdie behaves in the similar manner between fast and
immediate shutdown after 82233ce7ea42d6ba519. It is an side
effect of a change on immediate shutdown which make it to wait
the children to die by SIGQUIT.


Kyotaro Horiguchi
NTT Open Source Software Center

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to