Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Commit 60e956e

Browse files
committed
Fix control file update done in restartpoints still running after promotion
If a cluster is promoted (aka the control file shows a state different than DB_IN_ARCHIVE_RECOVERY) while CreateRestartPoint() is still processing, this function could miss an update of the control file for "checkPoint" and "checkPointCopy" but still do the recycling and/or removal of the past WAL segments, assuming that the to-be-updated LSN values should be used as reference points for the cleanup. This causes a follow-up restart attempting crash recovery to fail with a PANIC on a missing checkpoint record if the end-of-recovery checkpoint triggered by the promotion did not complete while the cluster abruptly stopped or crashed before the completion of this checkpoint. The PANIC would be caused by the redo LSN referred in the control file as located in a segment already gone, recycled by the previous restartpoint with "checkPoint" out-of-sync in the control file. This commit fixes the update of the control file during restartpoints so as "checkPoint" and "checkPointCopy" are updated even if the cluster has been promoted while a restartpoint is running, to be on par with the set of WAL segments actually recycled in the end of CreateRestartPoint(). 7863ee4 has fixed this problem already on master, but the release timing of the latest point versions did not let me enough time to study and fix that on all the stable branches. Reported-by: Fujii Masao, Rui Zhao Author: Kyotaro Horiguchi Reviewed-by: Nathan Bossart, Michael Paquier Discussion: https://postgr.es/m/[email protected] Backpatch-through: 10
1 parent b53442f commit 60e956e

File tree

1 file changed

+29
-15
lines changed
  • src/backend/access/transam

1 file changed

+29
-15
lines changed

src/backend/access/transam/xlog.c

Lines changed: 29 additions & 15 deletions
Original file line numberDiff line numberDiff line change
@@ -9470,22 +9470,27 @@ CreateRestartPoint(int flags)
94709470
PriorRedoPtr = ControlFile->checkPointCopy.redo;
94719471

94729472
/*
9473-
* Update pg_control, using current time. Check that it still shows
9474-
* IN_ARCHIVE_RECOVERY state and an older checkpoint, else do nothing;
9475-
* this is a quick hack to make sure nothing really bad happens if somehow
9476-
* we get here after the end-of-recovery checkpoint.
9473+
* Update pg_control, using current time. Check that it still shows an
9474+
* older checkpoint, else do nothing; this is a quick hack to make sure
9475+
* nothing really bad happens if somehow we get here after the
9476+
* end-of-recovery checkpoint.
94779477
*/
94789478
LWLockAcquire(ControlFileLock, LW_EXCLUSIVE);
9479-
if (ControlFile->state == DB_IN_ARCHIVE_RECOVERY &&
9480-
ControlFile->checkPointCopy.redo < lastCheckPoint.redo)
9479+
if (ControlFile->checkPointCopy.redo < lastCheckPoint.redo)
94819480
{
9481+
/*
9482+
* Update the checkpoint information. We do this even if the cluster
9483+
* does not show DB_IN_ARCHIVE_RECOVERY to match with the set of WAL
9484+
* segments recycled below.
9485+
*/
94829486
ControlFile->prevCheckPoint = ControlFile->checkPoint;
94839487
ControlFile->checkPoint = lastCheckPointRecPtr;
94849488
ControlFile->checkPointCopy = lastCheckPoint;
94859489
ControlFile->time = (pg_time_t) time(NULL);
94869490

94879491
/*
9488-
* Ensure minRecoveryPoint is past the checkpoint record. Normally,
9492+
* Ensure minRecoveryPoint is past the checkpoint record and update it
9493+
* if the control file still shows DB_IN_ARCHIVE_RECOVERY. Normally,
94899494
* this will have happened already while writing out dirty buffers,
94909495
* but not necessarily - e.g. because no buffers were dirtied. We do
94919496
* this because a non-exclusive base backup uses minRecoveryPoint to
@@ -9494,18 +9499,27 @@ CreateRestartPoint(int flags)
94949499
* at a minimum. Note that for an ordinary restart of recovery there's
94959500
* no value in having the minimum recovery point any earlier than this
94969501
* anyway, because redo will begin just after the checkpoint record.
9502+
* this because a non-exclusive base backup uses minRecoveryPoint to
9503+
* determine which WAL files must be included in the backup, and the
9504+
* file (or files) containing the checkpoint record must be included,
9505+
* at a minimum. Note that for an ordinary restart of recovery there's
9506+
* no value in having the minimum recovery point any earlier than this
9507+
* anyway, because redo will begin just after the checkpoint record.
94979508
*/
9498-
if (ControlFile->minRecoveryPoint < lastCheckPointEndPtr)
9509+
if (ControlFile->state == DB_IN_ARCHIVE_RECOVERY)
94999510
{
9500-
ControlFile->minRecoveryPoint = lastCheckPointEndPtr;
9501-
ControlFile->minRecoveryPointTLI = lastCheckPoint.ThisTimeLineID;
9511+
if (ControlFile->minRecoveryPoint < lastCheckPointEndPtr)
9512+
{
9513+
ControlFile->minRecoveryPoint = lastCheckPointEndPtr;
9514+
ControlFile->minRecoveryPointTLI = lastCheckPoint.ThisTimeLineID;
95029515

9503-
/* update local copy */
9504-
minRecoveryPoint = ControlFile->minRecoveryPoint;
9505-
minRecoveryPointTLI = ControlFile->minRecoveryPointTLI;
9516+
/* update local copy */
9517+
minRecoveryPoint = ControlFile->minRecoveryPoint;
9518+
minRecoveryPointTLI = ControlFile->minRecoveryPointTLI;
9519+
}
9520+
if (flags & CHECKPOINT_IS_SHUTDOWN)
9521+
ControlFile->state = DB_SHUTDOWNED_IN_RECOVERY;
95069522
}
9507-
if (flags & CHECKPOINT_IS_SHUTDOWN)
9508-
ControlFile->state = DB_SHUTDOWNED_IN_RECOVERY;
95099523
UpdateControlFile();
95109524
}
95119525
LWLockRelease(ControlFileLock);

0 commit comments

Comments
 (0)