| From: | Koshino Taiki <koshino(at)sraoss(dot)co(dot)jp> |
|---|---|
| To: | Nadav Shatz <nadav(at)tailorbrands(dot)com> |
| Cc: | "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 04:20:40 |
| Message-ID: | OS9P286MB648675F73B1CC987732202BD94B62@OS9P286MB6486.JPNP286.PROD.OUTLOOK.COM |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgpool-hackers |
> 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<mailto: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<mailto: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/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Koshino Taiki | 2026-09-03 04:45:47 | Re: Delimit query-cache key to prevent collisions |
| Previous Message | Roy, Dibyandu | 2026-09-02 18:35:22 | Proposal: PCP command for watchdog leader switchover (TODO: "Pgpool-II leader node switchover") |