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

Commit4a9a5bb

Browse files
committed
Ensure correct minimum consistent point on standbys
Startup process has improved its calculation of incorrect minimumconsistent point in8d68ee6, which ensures that all WAL available getsreplayed when doing crash recovery, and has introduced an incorrectcalculation of the minimum recovery point for non-startup processes,which can cause incorrect page references on a standby when for examplethe background writer flushed a couple of pages on-disk but was notupdating the control file to let a subsequent crash recovery replay towhere it should have.The only case where this has been reported to be a problem is when astandby needs to calculate the latest removed xid when replaying a btreedeletion record, so one would need connections on a standby that happenjust after recovery has thought it reached a consistent point. Using abackground worker which is started after the consistent point is reachedwould be the easiest way to get into problems if it connects to adatabase. Having clients which attempt to connect periodically couldalso be a problem, but the odds of seeing this problem are much lower.The fix used is pretty simple, as the idea is to give access to theminimum recovery point written in the control file to non-startupprocesses so as they use a reference, while the startup process stillinitializes its own references of the minimum consistent point so as theoriginal problem with incorrect page references happening post-promotionwith a crash do not show up.Reported-by: Alexander KukushkinDiagnosed-by: Alexander KukushkinAuthor: Michael PaquierReviewed-by: Kyotaro Horiguchi, Alexander KukushkinDiscussion:https://postgr.es/m/153492341830.1368.3936905691758473953@wrigleys.postgresql.orgBackpatch-through: 9.3
1 parent5fed7b2 commit4a9a5bb

File tree

1 file changed

+25
-6
lines changed
  • src/backend/access/transam

1 file changed

+25
-6
lines changed

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

Lines changed: 25 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -2543,9 +2543,13 @@ UpdateMinRecoveryPoint(XLogRecPtr lsn, bool force)
25432543
* i.e., we're doing crash recovery. We never modify the control file's
25442544
* value in that case, so we can short-circuit future checks here too. The
25452545
* local values of minRecoveryPoint and minRecoveryPointTLI should not be
2546-
* updated until crash recovery finishes.
2546+
* updated until crash recovery finishes. We only do this for the startup
2547+
* process as it should not update its own reference of minRecoveryPoint
2548+
* until it has finished crash recovery to make sure that all WAL
2549+
* available is replayed in this case. This also saves from extra locks
2550+
* taken on the control file from the startup process.
25472551
*/
2548-
if (XLogRecPtrIsInvalid(minRecoveryPoint))
2552+
if (XLogRecPtrIsInvalid(minRecoveryPoint)&&InRecovery)
25492553
{
25502554
updateMinRecoveryPoint= false;
25512555
return;
@@ -2557,7 +2561,9 @@ UpdateMinRecoveryPoint(XLogRecPtr lsn, bool force)
25572561
minRecoveryPoint=ControlFile->minRecoveryPoint;
25582562
minRecoveryPointTLI=ControlFile->minRecoveryPointTLI;
25592563

2560-
if (force||minRecoveryPoint<lsn)
2564+
if (XLogRecPtrIsInvalid(minRecoveryPoint))
2565+
updateMinRecoveryPoint= false;
2566+
elseif (force||minRecoveryPoint<lsn)
25612567
{
25622568
XLogRecPtrnewMinRecoveryPoint;
25632569
TimeLineIDnewMinRecoveryPointTLI;
@@ -2946,9 +2952,11 @@ XLogNeedsFlush(XLogRecPtr record)
29462952
* An invalid minRecoveryPoint means that we need to recover all the
29472953
* WAL, i.e., we're doing crash recovery. We never modify the control
29482954
* file's value in that case, so we can short-circuit future checks
2949-
* here too.
2955+
* here too. This triggers a quick exit path for the startup process,
2956+
* which cannot update its local copy of minRecoveryPoint as long as
2957+
* it has not replayed all WAL available when doing crash recovery.
29502958
*/
2951-
if (XLogRecPtrIsInvalid(minRecoveryPoint))
2959+
if (XLogRecPtrIsInvalid(minRecoveryPoint)&&InRecovery)
29522960
updateMinRecoveryPoint= false;
29532961

29542962
/* Quick exit if already known to be updated or cannot be updated */
@@ -2965,8 +2973,19 @@ XLogNeedsFlush(XLogRecPtr record)
29652973
minRecoveryPointTLI=ControlFile->minRecoveryPointTLI;
29662974
LWLockRelease(ControlFileLock);
29672975

2976+
/*
2977+
* Check minRecoveryPoint for any other process than the startup
2978+
* process doing crash recovery, which should not update the control
2979+
* file value if crash recovery is still running.
2980+
*/
2981+
if (XLogRecPtrIsInvalid(minRecoveryPoint))
2982+
updateMinRecoveryPoint= false;
2983+
29682984
/* check again */
2969-
returnrecord>minRecoveryPoint;
2985+
if (record <=minRecoveryPoint|| !updateMinRecoveryPoint)
2986+
return false;
2987+
else
2988+
return true;
29702989
}
29712990

29722991
/* Quick exit if already known flushed */

0 commit comments

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