Skip to content

Commit 0810fbb

Browse files
akorotkovamitkapila
andcommitted
Update comment for ReplicationSlot.last_saved_restart_lsn
Document that restart_lsn can go backwards and explain why this could happen. Discussion: https://postgr.es/m/1d12d2-67235980-35-19a406a0%4063439497 Discussion: https://postgr.es/m/CAPpHfdvuyMrUg0Vs5jPfwLOo1M9B-GP5j_My9URnBX0B%3DnrHKw%40mail.gmail.com Author: Hayato Kuroda <kuroda.hayato@fujitsu.com> Co-authored-by: Amit Kapila <amit.kapila16@gmail.com> Reviewed-by: Vignesh C <vignesh21@gmail.com> Reviewed-by: Amit Kapila <amit.kapila16@gmail.com> Reviewed-by: Alexander Korotkov <aekorotkov@gmail.com>
1 parent da71717 commit 0810fbb

File tree

1 file changed

+19
-0
lines changed

1 file changed

+19
-0
lines changed

src/include/replication/slot.h

Lines changed: 19 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -220,6 +220,25 @@ typedef struct ReplicationSlot
220220
* Latest restart_lsn that has been flushed to disk. For persistent slots
221221
* the flushed LSN should be taken into account when calculating the
222222
* 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.
223242
*/
224243
XLogRecPtr last_saved_restart_lsn;
225244

0 commit comments

Comments
 (0)