Hello. I happened to notice a wrong function name in the comment of XLogReadDetermineTimeline.
* The caller must also make sure it doesn't read past the current replay * position (using GetWalRcvWriteRecPtr) if executing in recovery, so it The comment is mentioning "replay position" and the callers are actually using GetXLogReplayRecPtr to check TLI and target LSN. The comment was written in that way when the function is introduced by 1148e22a82. The attached fixes that. The function GetWalRcvWriteRecPtr is not called from anywhere in core but I don't think we need to bother removing it since it is a public function. regards. -- Kyotaro Horiguchi NTT Open Source Software Center
diff --git a/src/backend/access/transam/xlogutils.c b/src/backend/access/transam/xlogutils.c index bbd801513a..0bb69447c2 100644 --- a/src/backend/access/transam/xlogutils.c +++ b/src/backend/access/transam/xlogutils.c @@ -681,10 +681,10 @@ XLogTruncateRelation(RelFileNode rnode, ForkNumber forkNum, * copied to a new timeline. * * The caller must also make sure it doesn't read past the current replay - * position (using GetWalRcvWriteRecPtr) if executing in recovery, so it + * position (using GetXLogReplayRecPtr) if executing in recovery, so it * doesn't fail to notice that the current timeline became historical. The * caller must also update ThisTimeLineID with the result of - * GetWalRcvWriteRecPtr and must check RecoveryInProgress(). + * GetXLogReplayRecPtr and must check RecoveryInProgress(). */ void XLogReadDetermineTimeline(XLogReaderState *state, XLogRecPtr wantPage, uint32 wantLength)
