Re: Allow reading LSN written by walreciever, but not flushed yet

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,
Rahila Syed