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)