MIME-Version: 1.0
References: 
 <CAKoxK+7_Wz0M3pu-=AG=LPV_npFuZG+n6mcWQvD0Zzp7abXoqQ@mail.gmail.com>
 <20251104.113219.411936663096048386.ishii@postgresql.org>
In-Reply-To: <20251104.113219.411936663096048386.ishii@postgresql.org>
From: Luca Ferrari <fluca1978@gmail.com>
Date: Thu, 6 Nov 2025 09:06:11 +0100
Message-ID: 
 <CAKoxK+5D5EZvqW13Eh3rM+S_trbTF9W7LVFFD4u3ox=WyymLuA@mail.gmail.com>
Subject: Re: rebooting a standby causes it go down on pgpool side
To: Tatsuo Ishii <ishii@postgresql.org>
Cc: pgpool-general@lists.postgresql.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAKoxK%2B5D5EZvqW13Eh3rM%2BS_trbTF9W7LVFFD4u3ox%3DWyymLuA%40mail.gmail.com>
Precedence: bulk

On Tue, Nov 4, 2025 at 3:32=E2=80=AFAM Tatsuo Ishii <ishii@postgresql.org> =
wrote:
>
> From the official document:
> "2 - Node is up. Connections are pooled."
> https://www.pgpool.net/docs/latest/en/html/pcp-node-info.html
>
> So you can safely assume that "waiting" also meabs node is up (for
> pgpool).  To change the status from "waiting" to "up", you can issue
> any SQL command (for example show pool_nodes") to pgpool.
>

Thanks, it is clear now!

> I think what happens there is, pgpool's health check detects
> PostgreSQL on pg3 goes down and trigger failover on pg3 pgpool.  As
> stated somewhere in the official docs, pgpool automatically sets
> PostgreSQL to down status, but not automatically change the status to
> up (or waiting). This is not a bug. It's by design.  If you want to
> make the status to up automatically, please consider using
> auto_failback.

Thanks, I was not assuming it was a bug, only asking for confirmation
about this behavior.

>
> If you want to avoid the failover, you can tweak the health check
> parameters so that while PostgreSQL rebooting, the health check
> repeatedly retries.  For example, increase health_check_max_retries.
> Note that health_check parameters can be changed by reloading
> pgpool.conf. So you can change the parameter and restore to previous
> value without rebooting pgpool.

Definetely a choice, but on the other hand increasing the number of
retries will make pgpool unable to "quickly" catch a real failover, so
I guess it is better, in my case, to deal with the "down" status after
a reboot.

Thanks,
Luca