]> granicus.if.org Git - postgresql/commit
Fix (re-)starting from a basebackup taken off a standby after a failure.
authorAndres Freund <andres@anarazel.de>
Thu, 18 Dec 2014 07:35:27 +0000 (08:35 +0100)
committerAndres Freund <andres@anarazel.de>
Thu, 18 Dec 2014 07:47:33 +0000 (08:47 +0100)
commita652b0c78c4f4bca8862a21aa8bba7ec35e305aa
treeddb1487500e666fc5a0548557e01ce846e380f98
parent0046f651da3ef0b73c3e16672e1198607c2d2ce5
Fix (re-)starting from a basebackup taken off a standby after a failure.

When starting up from a basebackup taken off a standby extra logic has
to be applied to compute the point where the data directory is
consistent. Normal base backups use a WAL record for that purpose, but
that isn't possible on a standby.

That logic had a error check ensuring that the cluster's control file
indicates being in recovery. Unfortunately that check was too strict,
disregarding the fact that the control file could also indicate that
the cluster was shut down while in recovery.

That's possible when the a cluster starting from a basebackup is shut
down before the backup label has been removed. When everything goes
well that's a short window, but when either restore_command or
primary_conninfo isn't configured correctly the window can get much
wider. That's because inbetween reading and unlinking the label we
restore the last checkpoint from WAL which can need additional WAL.

To fix simply also allow starting when the control file indicates
"shutdown in recovery". There's nicer fixes imaginable, but they'd be
more invasive.

Backpatch to 9.2 where support for taking basebackups from standbys
was added.
src/backend/access/transam/xlog.c