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

Commit8b34cff

Browse files
committed
Add more LOG messages when starting and ending recovery from a backup
Three LOG messages are added in the recovery code paths, providinginformation that can be useful to track corruption issues depending onthe state of the cluster, telling that:- Recovery has started from a backup_label.- Recovery is restarting from a backup start LSN, without abackup_label.- Recovery has completed from a backup.This was originally applied on HEAD as of1d35f70, and there isconsensus that this can be useful for older versions. This appliescleanly down to 15, so do it down to this version for now (olderversions have heavily refactored the WAL recovery paths, making thechange less straight-forward to do).Author: Andres FreundReviewed-by: David Steele, Laurenz Albe, Michael PaquierDiscussion:https://postgr.es/m/20231117041811.vz4vgkthwjnwp2pp@awork3.anarazel.deBackpatch-through: 15
1 parent86b6243 commit8b34cff

File tree

1 file changed

+34
-0
lines changed

1 file changed

+34
-0
lines changed

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

Lines changed: 34 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -621,6 +621,22 @@ InitWalRecovery(ControlFileData *ControlFile, bool *wasShutdown_ptr,
621621
if (StandbyModeRequested)
622622
EnableStandbyMode();
623623

624+
/*
625+
* Omitting backup_label when creating a new replica, PITR node etc.
626+
* unfortunately is a common cause of corruption. Logging that
627+
* backup_label was used makes it a bit easier to exclude that as the
628+
* cause of observed corruption.
629+
*
630+
* Do so before we try to read the checkpoint record (which can fail),
631+
* as otherwise it can be hard to understand why a checkpoint other
632+
* than ControlFile->checkPoint is used.
633+
*/
634+
ereport(LOG,
635+
(errmsg("starting backup recovery with redo LSN %X/%X, checkpoint LSN %X/%X, on timeline ID %u",
636+
LSN_FORMAT_ARGS(RedoStartLSN),
637+
LSN_FORMAT_ARGS(CheckPointLoc),
638+
CheckPointTLI)));
639+
624640
/*
625641
* When a backup_label file is present, we want to roll forward from
626642
* the checkpoint it identifies, rather than using pg_control.
@@ -759,6 +775,16 @@ InitWalRecovery(ControlFileData *ControlFile, bool *wasShutdown_ptr,
759775
EnableStandbyMode();
760776
}
761777

778+
/*
779+
* For the same reason as when starting up with backup_label present,
780+
* emit a log message when we continue initializing from a base
781+
* backup.
782+
*/
783+
if (!XLogRecPtrIsInvalid(ControlFile->backupStartPoint))
784+
ereport(LOG,
785+
(errmsg("restarting backup recovery with redo LSN %X/%X",
786+
LSN_FORMAT_ARGS(ControlFile->backupStartPoint))));
787+
762788
/* Get the last valid checkpoint record. */
763789
CheckPointLoc=ControlFile->checkPoint;
764790
CheckPointTLI=ControlFile->checkPointCopy.ThisTimeLineID;
@@ -2102,6 +2128,9 @@ CheckRecoveryConsistency(void)
21022128
if (!XLogRecPtrIsInvalid(backupEndPoint)&&
21032129
backupEndPoint <=lastReplayedEndRecPtr)
21042130
{
2131+
XLogRecPtrsaveBackupStartPoint=backupStartPoint;
2132+
XLogRecPtrsaveBackupEndPoint=backupEndPoint;
2133+
21052134
elog(DEBUG1,"end of backup reached");
21062135

21072136
/*
@@ -2112,6 +2141,11 @@ CheckRecoveryConsistency(void)
21122141
backupStartPoint=InvalidXLogRecPtr;
21132142
backupEndPoint=InvalidXLogRecPtr;
21142143
backupEndRequired= false;
2144+
2145+
ereport(LOG,
2146+
(errmsg("completed backup recovery with redo LSN %X/%X and end LSN %X/%X",
2147+
LSN_FORMAT_ARGS(saveBackupStartPoint),
2148+
LSN_FORMAT_ARGS(saveBackupEndPoint))));
21152149
}
21162150

21172151
/*

0 commit comments

Comments
 (0)

[8]ページ先頭

©2009-2025 Movatter.jp