Re: Allow reading LSN written by walreciever, but not flushed yet - Mailing list pgsql-hackers
Hi,I've been following this discussion and have a question I'd like to ask.
XLogWalRcvFlush() only updates flushedUpto if LogstreamResult.Flush has advanced,
while XLogWalRcvWrite() updates writtenUpto unconditionally. That means the flush
LSN (as reported by pg_last_wal_receive_lsn()) never moves backward, whereas
the write LSN might. Because of this difference in behavior, I was thinking that
we might need to track the maximum write LSN seen so far and have the function
return that value.
Can you please explain the scenarios in which the record pointer of the WAL record written
by the receiver can move backwards.
For example, in physical replication, the WAL records are sent after a Flush on the primary in ascending
order of XLogRecPtr. They are also received in that order and written as they arrive by the receiver.
Are you referring to crash scenarios where unflushed WAL may be discarded and receiver has
to move backwards and start from the last flushed record on the standby?
Thank you,
by the receiver can move backwards.
For example, in physical replication, the WAL records are sent after a Flush on the primary in ascending
order of XLogRecPtr. They are also received in that order and written as they arrive by the receiver.
Are you referring to crash scenarios where unflushed WAL may be discarded and receiver has
to move backwards and start from the last flushed record on the standby?
Thank you,
Rahila Syed
pgsql-hackers by date: