On Tue, Mar 10, 2026 at 10:54 AM Fujii Masao <[email protected]> wrote: > Even with your latest patch, if we remove fullyAppliedLastTime, and set > clearLagTimes to true when applyPtr == sentPtr && noLagSamples && > positionsUnchanged, > wouldn't the time for the lag to become NULL be almost the same as > wal_receiver_status_interval? > > The documentation doesn't clearly specify how long it should take for > the lag to become NULL, so doubling that time might be acceptable. > However, if we can keep it roughly the same without much complexity, > I think that would be preferable. > > Thought?
Thank you for the suggestion. I tested this by removing fullyAppliedLastTime, but even with synchronous replication, NULL still appears. Here is why: - Reply 1 (flush notification): positions = X. Lag samples are consumed with real values, so noLagSamples = false. clearLagTimes is not set, and prevPtrs = X is saved. - Reply 2 (force_reply): positions = X again. Here, noLagSamples = true and positionsUnchanged = true. Since applyPtr == sentPtr, clearLagTimes is set to true, resulting in a NULL value. Therefore, I believe fullyAppliedLastTime is still necessary to ensure that the previous reply also contained no lag samples. BTW I noticed an incorrect comment in walreceiver.c and have included a fix for it. Patch 0001 remains unchanged. -- Best regards, Shinya Kato NTT OSS Center
v3-0001-Fix-spurious-NULL-lag-in-pg_stat_replication.patch
Description: Binary data
v3-0002-Fix-a-comment-in-walreceiver.c.patch
Description: Binary data
