Skip to content

Commit e513a3d

Browse files
committed
Rework activation of commit timestamps during recovery
The activation and deactivation of commit timestamp tracking has not been handled consistently for a primary or standbys at recovery. The facility can be activated at three different moments of recovery: - The beginning, where a primary would use the GUC value for the decision-making, and where a standby relies on the contents of the control file. - When replaying a XLOG_PARAMETER_CHANGE record at redo. - The end, where both primary and standby rely on the GUC value. Using the GUC value for a primary at the beginning of recovery causes problems with commit timestamp access when doing crash recovery. Particularly, when replaying transaction commits, it could be possible that an attempt to read commit timestamps is done for a transaction which committed at a moment when track_commit_timestamp was disabled. A test case is added to reproduce the failure. The test works down to v11 as it takes advantage of transaction commits within procedures. Reported-by: Hailong Li Author: Masahiko Sawasa, Michael Paquier Reviewed-by: Kyotaro Horiguchi Discussion: https://postgr.es/m/11224478-a782-203b-1f17-e4797b39bdf0@qunar.com Backpatch-through: 9.5, where commit timestamps have been introduced.
1 parent 0a4456a commit e513a3d

File tree

2 files changed

+9
-9
lines changed

2 files changed

+9
-9
lines changed

src/backend/access/transam/commit_ts.c

Lines changed: 4 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -572,10 +572,9 @@ CompleteCommitTsInitialization(void)
572572
* any leftover data.
573573
*
574574
* Conversely, we activate the module if the feature is enabled. This is
575-
* not necessary in a master system because we already did it earlier, but
576-
* if we're in a standby server that got promoted which had the feature
577-
* enabled and was following a master that had the feature disabled, this
578-
* is where we turn it on locally.
575+
* necessary for primary and standby as the activation depends on the
576+
* control file contents at the beginning of recovery or when a
577+
* XLOG_PARAMETER_CHANGE is replayed.
579578
*/
580579
if (!track_commit_timestamp)
581580
DeactivateCommitTs();
@@ -585,7 +584,7 @@ CompleteCommitTsInitialization(void)
585584

586585
/*
587586
* Activate or deactivate CommitTs' upon reception of a XLOG_PARAMETER_CHANGE
588-
* XLog record in a standby.
587+
* XLog record during recovery.
589588
*/
590589
void
591590
CommitTsParameterChange(bool newvalue, bool oldvalue)

src/backend/access/transam/xlog.c

Lines changed: 5 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -6467,11 +6467,12 @@ StartupXLOG(void)
64676467
StartupMultiXact();
64686468

64696469
/*
6470-
* Ditto commit timestamps. In a standby, we do it if setting is enabled
6471-
* in ControlFile; in a master we base the decision on the GUC itself.
6470+
* Ditto for commit timestamps. Activate the facility if the setting is
6471+
* enabled in the control file, as there should be no tracking of commit
6472+
* timestamps done when the setting was disabled. This facility can be
6473+
* started or stopped when replaying a XLOG_PARAMETER_CHANGE record.
64726474
*/
6473-
if (ArchiveRecoveryRequested ?
6474-
ControlFile->track_commit_timestamp : track_commit_timestamp)
6475+
if (ControlFile->track_commit_timestamp)
64756476
StartupCommitTs();
64766477

64776478
/*

0 commit comments

Comments
 (0)