Date: Tue, 19 May 2026 21:40:37 +0900 (JST)
Message-Id: <20260519.214037.579991005061650329.ishii@postgresql.org>
To: emond.papegaaij@gmail.com
Cc: pgpool-hackers@lists.postgresql.org
Subject: Re: Primary node detection race at clean startup
From: Tatsuo Ishii <ishii@postgresql.org>
In-Reply-To: 
 <CAGXsc+ZmBoLs3Mz=G-Bdm4JJG+fH1NpHfR3qVJVwW4eBKWwStQ@mail.gmail.com>
References: 
 <CAGXsc+ZmBoLs3Mz=G-Bdm4JJG+fH1NpHfR3qVJVwW4eBKWwStQ@mail.gmail.com>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-2022-jp
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/20260519.214037.579991005061650329.ishii%40postgresql.org>
Precedence: bulk

Hi Emond,

> Hi,
> 
> In our tests, we've found an issue that can cause all Pgpool nodes to
> report an incorrect 'Role: standby':
> Role                   : standby    ← stale, never updated on this node
> Backend Role           : primary    ← actual SR-check result
> 
> This can happen if all nodes in a watchdog cluster start with a clean
> state at the same time. If the first node is still trying to determine
> the primary database, it's primary_node_id is -2. This value is then
> synced to other nodes in the cluster, causing all nodes to report the
> stale state indefinitely. Attached is a patch against 4.7 that should
> fix this.
> 
> Note that this analysis was done by Claude Code and it also created
> the patch. The failure on our CI was real though and I think the
> explanation makes sense.

I have looked into the patch. Although I failed to reproduce the
issue, I agree with you: the explanation makes sense. Also I have run
the regression test and all test passed. I am going to push the patch
to all supported branches.

Regards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp