On Mon, Mar 9, 2026 at 8:21 PM Fujii Masao <[email protected]> wrote: > > The attached v2 patch takes a different approach: it additionally > > requires that all reported positions (write/flush/apply) remain > > unchanged from the previous reply. This directly detects a truly idle > > system without relying on timeouts—if any position has advanced, new > > WAL activity must have occurred, so we should not clear the lag values > > even if the lag tracker is empty. > > This approach looks good to me.
Thank you for looking into this. > One comment: currently, the lag becomes NULL basically after about one > wal_receiver_status_interval during periods of no activity. OTOH, with this > approach, it seems it would take about twice wal_receiver_status_interval. > Is this understanding correct? Exactly. With this patch, it takes about two wal_receiver_status_interval cycles to show NULL instead of one. I think this is an acceptable trade-off because it is better to take a bit longer to detect inactivity than to incorrectly show NULL during active replication. -- Best regards, Shinya Kato NTT OSS Center
