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

On 2025/05/14 15:54, Alexander Kukushkin wrote:
> Hi Fujii,
>
>
> On Tue, 13 May 2025 at 13:13, Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com <mailto:masao(dot)fujii(at)oss(dot)nttdata(dot)com>> wrote:
>
> In this case, doesn't the flush LSN typically catch up to the write LSN on node2
> after a few seconds? Even if the walreceiver exits while there's still written
> but unflushed WAL, it looks like WalRcvDie() ensures everything is flushed by
> calling XLogWalRcvFlush(). So, isn't it safe to rely on the flush LSN when selecting
> the most advanced node? No?
>
>
> I think it is a bit more complex than that. There are also cases when we want to ensure that there are "healthy" standby nodes when switchover is requested.
> Meaning of "healthy" could be something like: "According to the write LSN it is not lagging more than 16MB" or similar.

Could we use the flush LSN instead of the write LSN for this?

By the way, in a switchover scenario where the primary is
shut down cleanly, it tries to send all remaining WAL records
to the standby before exiting. The walreceiver on the standby
then writes and flushes all those records before it exits.
So in this case, using the flush LSN to check for a "healthy"
state should work. But were you considering a different scenario?

Regards,

--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION