From c8793bdf8e204f8224deae9068261ceb2a048a18 Mon Sep 17 00:00:00 2001 From: Hayato Kuroda Date: Sun, 29 Jun 2025 15:19:29 +0900 Subject: [PATCH] Update comment for last_saved_restart_lsn --- src/include/replication/slot.h | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/src/include/replication/slot.h b/src/include/replication/slot.h index ffacba9d2ae..4481a4d0068 100644 --- a/src/include/replication/slot.h +++ b/src/include/replication/slot.h @@ -220,6 +220,25 @@ typedef struct ReplicationSlot * Latest restart_lsn that has been flushed to disk. For persistent slots * the flushed LSN should be taken into account when calculating the * oldest LSN for WAL segments removal. + * + * We cannot assume that restart_lsn will always move forward, i.e., that + * the previously flushed restart_lsn is always behind data.restart_lsn. In + * the case of streaming replication with a physical slot, the restart_lsn + * can be updated based on the flushed WAL position reported by the + * walreceiver. + * + * However, this type of replication allows duplicate WAL records to be + * received and overwritten. If the walreceiver receives older WAL records + * and then reports them as flushed to the walsender, the restart_lsn may + * appear to move backward. + * + * This behavior typically occurs at the beginning of replication. One + * reason is that streaming replication always starts at the beginning of a + * segment. If the current restart_lsn is in the middle of that segment, it + * may be updated to an earlier LSN. Another reason is that the walreceiver + * chooses its startpoint based on the replayed LSN. Some records might + * have been received but not yet applied; in such cases, they will be + * received again. */ XLogRecPtr last_saved_restart_lsn; -- 2.47.1