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

Commita652b0c

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 parent0046f65 commita652b0c

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
@@ -6633,11 +6633,17 @@ StartupXLOG(void)
66336633
/*
66346634
* Set backupStartPoint if we're starting recovery from a base backup.
66356635
*
6636-
*Set backupEndPoint and use minRecoveryPoint as the backup end
6636+
*Also set backupEndPoint and use minRecoveryPoint as the backup end
66376637
* location if we're starting recovery from a base backup which was
6638-
* taken from the standby. In this case, the database system status in
6639-
* pg_control must indicate DB_IN_ARCHIVE_RECOVERY. If not, which
6640-
* means that backup is corrupted, so we cancel recovery.
6638+
* taken from a standby. In this case, the database system status in
6639+
* pg_control must indicate that the database was already in
6640+
* recovery. Usually that will be DB_IN_ARCHIVE_RECOVERY but also can
6641+
* be DB_SHUTDOWNED_IN_RECOVERY if recovery previously was interrupted
6642+
* before reaching this point; e.g. because restore_command or
6643+
* primary_conninfo were faulty.
6644+
*
6645+
* Any other state indicates that the backup somehow became corrupted
6646+
* and we can't sensibly continue with recovery.
66416647
*/
66426648
if (haveBackupLabel)
66436649
{
@@ -6646,7 +6652,8 @@ StartupXLOG(void)
66466652

66476653
if (backupFromStandby)
66486654
{
6649-
if (dbstate_at_startup!=DB_IN_ARCHIVE_RECOVERY)
6655+
if (dbstate_at_startup!=DB_IN_ARCHIVE_RECOVERY&&
6656+
dbstate_at_startup!=DB_SHUTDOWNED_IN_RECOVERY)
66506657
ereport(FATAL,
66516658
(errmsg("backup_label contains data inconsistent with control file"),
66526659
errhint("This means that the backup is corrupted and you will "

0 commit comments

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