Обсуждение: A comment fix

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)

On Mon, May 11, 2020 at 10:16:19AM +0900, Kyotaro Horiguchi wrote:
> 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.

Looks right to me, so will fix if there are no objections.
read_local_xlog_page() uses the replay location when in recovery.

> 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.

Yes, I don't think that's removable (just look at the log message of
d140f2f3), and the function is dead simple so that's not really going
to break even if this is dead in-core now.  Worth noting some future
WAL prefetch stuff may actually use it.
--
Michael

On Mon, May 11, 2020 at 02:22:36PM +0900, Michael Paquier wrote:
> Looks right to me, so will fix if there are no objections.
> read_local_xlog_page() uses the replay location when in recovery.

Done this part now.
--
Michael

At Tue, 12 May 2020 14:45:22 +0900, Michael Paquier <michael@paquier.xyz> wrote in 
> On Mon, May 11, 2020 at 02:22:36PM +0900, Michael Paquier wrote:
> > Looks right to me, so will fix if there are no objections.
> > read_local_xlog_page() uses the replay location when in recovery.
> 
> Done this part now.

Thanks!

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center