On Fri, Dec 12, 2025 at 12:51:00PM +0800, Xuneng Zhou wrote: > Bug #19093 [1] reported that pg_stat_wal_receiver.status = 'streaming' > does not accurately reflect streaming health. In that discussion, > Noah noted that even before the reported regression, status = > 'streaming' was unreliable because walreceiver sets it during early > startup, before attempting a connection. He suggested: > > "Long-term, in master only, perhaps we should introduce another status > like 'connecting'. Perhaps enact the connecting->streaming status > transition just before tendering the first byte of streamed WAL to the > startup process. Alternatively, enact that transition when the startup > process accepts the > first streamed byte."
> == Proposal == > > Introduce WALRCV_CONNECTING as an intermediate state between STARTING > and STREAMING: > > - When walreceiver starts, it enters CONNECTING (instead of going > directly to STREAMING). > - The transition to STREAMING occurs in XLogWalRcvFlush(), inside the > existing spinlock-protected block that updates flushedUpto. I think this has the drawback that if the primary's WAL is incompatible, e.g. unacceptable timeline, the walreceiver will still briefly enter STREAMING. That could trick monitoring. Waiting for applyPtr to advance would avoid the short-lived STREAMING. What's the feasibility of that?
