| From: | Shinya Kato <shinya11(dot)kato(at)gmail(dot)com> |
|---|---|
| To: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: pg_stat_replication.*_lag sometimes shows NULL during active replication |
| Date: | 2026-03-10 01:01:45 |
| Message-ID: | CAOzEurQiP3uebd1GMiC1Dzf5VJwF4ZBEpJ6QYQFE6Y+rVjxqNA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Mar 9, 2026 at 8:21 PM Fujii Masao <masao(dot)fujii(at)gmail(dot)com> 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Fujii Masao | 2026-03-10 01:17:08 | Re: Add missing stats_reset column to pg_stat_database_conflicts view |
| Previous Message | yangyz | 2026-03-10 00:27:06 | Re: Avoid resource leak (src/bin/pg_dump/pg_dumpall.c) |