Re: Report replication delay as unknown for down standby nodes

From: Midnya <midnya(at)midnya(dot)cat>
To: Koshino Taiki <koshino(at)sraoss(dot)co(dot)jp>
Cc: Nadav Shatz <nadav(at)tailorbrands(dot)com>, "pgpool-hackers(at)lists(dot)postgresql(dot)org" <pgpool-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Report replication delay as unknown for down standby nodes
Date: 2026-09-03 17:39:38
Message-ID: a83PSfx7eej4kQqcmlUEiokx08TUDB7_c08dIqbLXlltO6dAgmJkBkhzqbr3xFJRyv6-sZyq079zXHt24ztRcF7uYA2T1eNyB5alubBVMh0=@midnya.cat
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgpool-hackers

Hello,

> I would also like to ask the other pgpool-hackers subscribers for their
opinions on this change.

While this would break our own monitoring parsers, my organization supports this
change, as 0 is currently interpreted as both "good state" and
"unknown". This makes it an unreliable metric, untrusted by operators, where
only a non-zero integer is seen as "meaningful".

We would not mind the breaking change and updating our tools to not report this
metric if it can be "unknown"

For what it's worth, our tools do expect a positive integer today.

Thank you,
Midnya <pgpool(at)midnya(dot)cat>

-------- Original Message --------
On Thursday, 09/03/26 at 06:21 Koshino Taiki <koshino(at)sraoss(dot)co(dot)jp> wrote:

> > I think unknown is clear and better than 0 or last known. 
>
> Hi Nadav,
>
> Thank you for your feedback.
> I agree that unknown expresses the actual state
> more clearly than either zero or the last known value.
>
> I would also like to ask the other pgpool-hackers subscribers
> for their opinions on this change.
>
> In particular, could changing replication_delay from a numeric
> value to the string unknown affect any third-party monitoring
> tools?
> For example, Prometheus exporters, Zabbix monitoring templates,
> pgpoolAdmin may parse this column and store it as a numeric metric.
>
> If such tools expect this field to always be numeric,
> reporting zero while the delay cannot be measured might be
> the safer option for compatibility,even though unknown is
> semantically more accurate.
> Does anyone know of tools that collect this column as a numeric value,
> or have a preference between unknown and zero?
>
> Regards,
>
> Taiki Koshino<koshino(at)sraoss(dot)co(dot)jp>
> SRA OSS K.K.
> TEL: 03-5979-2701 FAX: 03-5979-2702
> URL: https://www.sraoss.co.jp/
>
>
> 差出人: Nadav Shatz <nadav(at)tailorbrands(dot)com>
> 送信日時: 2026年9月2日 15:07
> 宛先: Koshino Taiki <koshino(at)sraoss(dot)co(dot)jp>
> CC: pgpool-hackers(at)lists(dot)postgresql(dot)org <pgpool-hackers(at)lists(dot)postgresql(dot)org>
> 件名: Re: Report replication delay as unknown for down standby nodes
>  
> I think unknown is clear and better than 0 or last known. 
>
>
> Nadav Shatz
> Tailor Brands | CTO
>
> On Wed, Sep 2, 2026 at 3:15 AM Koshino Taiki <koshino(at)sraoss(dot)co(dot)jp> wrote:
>
> > `Hi,
> >
> > I investigated and reproduced the replication delay reporting issue
> > reported here:
> >
> > https://github.com/pgpool/pgpool2/issues/131
> >
> > After generating replication delay and detaching the standby,
> > SHOW POOL_NODES and pcp_node_info continued to report the last measured
> > value:
> >
> >  status | pg_status | replication_delay
> >  -------+-----------+------------------
> >  down   | up        | 72354928
> >
> > Since the delay cannot be measured while the standby is down, this patch
> > reports it as "unknown" in both commands:
> >
> >  status | pg_status | replication_delay
> >  -------+-----------+------------------
> >  down   | up        | unknown
> >
> >  localhost 11003 ... down up standby standby unknown streaming async
> >
> > The stored value is left unchanged to avoid treating an unmeasured delay
> > as zero when the standby is attached again.
> >
> > I also updated the expected output of the 003.failover regression test,
> > and the test passes.
> >
> > Do you think "unknown" is the appropriate output, or would zero or the
> > last measured value be preferable?
> >
> > The patch is attached.
> >
> > Regards,
> > Taiki Koshino`
> >
> > Taiki Koshino<koshino(at)sraoss(dot)co(dot)jp>
> > SRA OSS K.K.
> > TEL: 03-5979-2701 FAX: 03-5979-2702
> > URL: https://www.sraoss.co.jp/
> >

In response to

Browse pgpool-hackers by date

  From Date Subject
Next Message Koshino Taiki 2026-09-04 06:33:22 Re: [PATCH v1] Fix hang on deferred constraint errors in pipeline mode
Previous Message Nadav Shatz 2026-09-03 06:01:13 Re: Report replication delay as unknown for down standby nodes