Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commitc303e9e

Browse files
committed
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 hasto be applied to compute the point where the data directory isconsistent. Normal base backups use a WAL record for that purpose, butthat isn't possible on a standby.That logic had a error check ensuring that the cluster's control fileindicates being in recovery. Unfortunately that check was too strict,disregarding the fact that the control file could also indicate thatthe cluster was shut down while in recovery.That's possible when the a cluster starting from a basebackup is shutdown before the backup label has been removed. When everything goeswell that's a short window, but when either restore_command orprimary_conninfo isn't configured correctly the window can get muchwider. That's because inbetween reading and unlinking the label werestore 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 bemore invasive.Backpatch to 9.2 where support for taking basebackups from standbyswas added.
1 parent40c598f commitc303e9e

File tree

1 file changed

+12
-5
lines changed
  • src/backend/access/transam

1 file changed

+12
-5
lines changed

‎src/backend/access/transam/xlog.c

Lines changed: 12 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -6070,11 +6070,17 @@ StartupXLOG(void)
60706070
/*
60716071
* Set backupStartPoint if we're starting recovery from a base backup.
60726072
*
6073-
*Set backupEndPoint and use minRecoveryPoint as the backup end
6073+
*Also set backupEndPoint and use minRecoveryPoint as the backup end
60746074
* location if we're starting recovery from a base backup which was
6075-
* taken from the standby. In this case, the database system status in
6076-
* pg_control must indicate DB_IN_ARCHIVE_RECOVERY. If not, which
6077-
* means that backup is corrupted, so we cancel recovery.
6075+
* taken from a standby. In this case, the database system status in
6076+
* pg_control must indicate that the database was already in
6077+
* recovery. Usually that will be DB_IN_ARCHIVE_RECOVERY but also can
6078+
* be DB_SHUTDOWNED_IN_RECOVERY if recovery previously was interrupted
6079+
* before reaching this point; e.g. because restore_command or
6080+
* primary_conninfo were faulty.
6081+
*
6082+
* Any other state indicates that the backup somehow became corrupted
6083+
* and we can't sensibly continue with recovery.
60786084
*/
60796085
if (haveBackupLabel)
60806086
{
@@ -6083,7 +6089,8 @@ StartupXLOG(void)
60836089

60846090
if (backupFromStandby)
60856091
{
6086-
if (dbstate_at_startup!=DB_IN_ARCHIVE_RECOVERY)
6092+
if (dbstate_at_startup!=DB_IN_ARCHIVE_RECOVERY&&
6093+
dbstate_at_startup!=DB_SHUTDOWNED_IN_RECOVERY)
60876094
ereport(FATAL,
60886095
(errmsg("backup_label contains data inconsistent with control file"),
60896096
errhint("This means that the backup is corrupted and you will "

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp