Re: what is causing different pcp_node_info status

From: Tatsuo Ishii <ishii(at)postgresql(dot)org>
To: fluca1978(at)gmail(dot)com
Cc: pgpool-general(at)lists(dot)postgresql(dot)org
Subject: Re: what is causing different pcp_node_info status
Date: 2025-11-04 01:36:53
Message-ID: 20251104.103653.1591539302067481630.ishii@postgresql.org
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgpool-general

> On Thu, Oct 23, 2025 at 8:04 AM Luca Ferrari <fluca1978(at)gmail(dot)com> wrote:
>>
>> I am still observing the issue, the best situation I come is all nodes
>> reported as "up up" when queryed on pg1 (primary) and "waiting up"
>> when queried from pg2 and pg3.
>> could it be network latency or a similar issue?
>
> As explained clearly here
> <https://github.com/pgpool/pgpool2/issues/131#issuecomment-3436197043>
> the information about the nodes is collected and kept in shared
> memory.
> Is there any chance the same process is applied to the pgpool node status?
> I observed that even a machine reboot does not seem to make pgpool
> report a status better than "waiting up", evne after minutes, and
> while replicas are streaming.
> Restarting then the pgpool service brings the status "up up", this
> makes me think there is something blocking or delaying pgpool to
> collect data, and when the service is restarted the node is forced to
> "dig" the other node status.
> Something I could investigate on?

You are misunderstanding what "waiting" means. It means "Node is
up. No connections yet." [1] If you are only interested in the node is up
or down, you can safely assume that "waiting" == "up".

Best regards,
[1] https://www.pgpool.net/docs/latest/en/html/pcp-node-info.html
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp

In response to

Browse pgpool-general by date

  From Date Subject
Next Message Tatsuo Ishii 2025-11-04 02:32:19 Re: rebooting a standby causes it go down on pgpool side
Previous Message Tatsuo Ishii 2025-11-04 01:28:34 Re: Autofail back inconsistent