@@ -220,6 +220,25 @@ typedef struct ReplicationSlot
220
220
* Latest restart_lsn that has been flushed to disk. For persistent slots
221
221
* the flushed LSN should be taken into account when calculating the
222
222
* oldest LSN for WAL segments removal.
223
+ *
224
+ * Do not assume that restart_lsn will always move forward, i.e., that the
225
+ * previously flushed restart_lsn is always behind data.restart_lsn. In
226
+ * streaming replication using a physical slot, the restart_lsn is updated
227
+ * based on the flushed WAL position reported by the walreceiver.
228
+ *
229
+ * This replication mode allows duplicate WAL records to be received and
230
+ * overwritten. If the walreceiver receives older WAL records and then
231
+ * reports them as flushed to the walsender, the restart_lsn may appear to
232
+ * move backward.
233
+ *
234
+ * This typically occurs at the beginning of replication. One reason is
235
+ * that streaming replication starts at the beginning of a segment, so, if
236
+ * restart_lsn is in the middle of a segment, it will be updated to an
237
+ * earlier LSN, see RequestXLogStreaming. Another reason is that the
238
+ * walreceiver chooses its startpoint based on the replayed LSN, so, if
239
+ * some records have been received but not yet applied, they will be
240
+ * received again and leads to updating the restart_lsn to an earlier
241
+ * position.
223
242
*/
224
243
XLogRecPtr last_saved_restart_lsn ;
225
244
0 commit comments