From: Andres Freund Date: Thu, 18 Dec 2014 07:35:27 +0000 (+0100) Subject: Fix (re-)starting from a basebackup taken off a standby after a failure. X-Git-Tag: REL9_4_1~91 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=ce083254919d08043fc5c8b060f322f6bc84d1c0;p=postgresql 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. --- diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c index 30446a4dc1..b2443c082e 100644 --- a/src/backend/access/transam/xlog.c +++ b/src/backend/access/transam/xlog.c @@ -6445,11 +6445,17 @@ StartupXLOG(void) /* * Set backupStartPoint if we're starting recovery from a base backup. * - * Set backupEndPoint and use minRecoveryPoint as the backup end + * Also set backupEndPoint and use minRecoveryPoint as the backup end * location if we're starting recovery from a base backup which was - * taken from the standby. In this case, the database system status in - * pg_control must indicate DB_IN_ARCHIVE_RECOVERY. If not, which - * means that backup is corrupted, so we cancel recovery. + * taken from a standby. In this case, the database system status in + * pg_control must indicate that the database was already in + * recovery. Usually that will be DB_IN_ARCHIVE_RECOVERY but also can + * be DB_SHUTDOWNED_IN_RECOVERY if recovery previously was interrupted + * before reaching this point; e.g. because restore_command or + * primary_conninfo were faulty. + * + * Any other state indicates that the backup somehow became corrupted + * and we can't sensibly continue with recovery. */ if (haveBackupLabel) { @@ -6458,7 +6464,8 @@ StartupXLOG(void) if (backupFromStandby) { - if (dbstate_at_startup != DB_IN_ARCHIVE_RECOVERY) + if (dbstate_at_startup != DB_IN_ARCHIVE_RECOVERY && + dbstate_at_startup != DB_SHUTDOWNED_IN_RECOVERY) ereport(FATAL, (errmsg("backup_label contains data inconsistent with control file"), errhint("This means that the backup is corrupted and you will "