On 2025/05/14 15:54, Alexander Kukushkin wrote:
Hi Fujii, On Tue, 13 May 2025 at 13:13, Fujii Masao <masao.fu...@oss.nttdata.com <mailto:masao.fu...@oss.nttdata.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
