| 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
| 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 |