MIME-Version: 1.0
References: 
 <CAGXsc+ZM=aE=ibSDintubM8Ni8kfeaXK963Xca05j-SBYLPhhA@mail.gmail.com>
 <20251231.165714.1023017053914495270.ishii@postgresql.org>
 <CAGXsc+au8Wzjsuk1z-mqPFLfpkjQZSPneLLVbnkUs5rAMXNF=A@mail.gmail.com>
 <20260122.093003.1821723338788147775.ishii@postgresql.org>
In-Reply-To: <20260122.093003.1821723338788147775.ishii@postgresql.org>
From: Emond Papegaaij <emond.papegaaij@gmail.com>
Date: Thu, 22 Jan 2026 11:05:20 +0100
Message-ID: 
 <CAGXsc+Yg8Y2xxPDtNNYekNvG+ABtzb9GtxuwrbfrBDMJXGVX9w@mail.gmail.com>
Subject: Re: Pgpool-II 4.7.0 released.
To: Tatsuo Ishii <ishii@postgresql.org>
Cc: pgpool-general@lists.postgresql.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
 <https://www.postgresql.org/message-id/CAGXsc%2BYg8Y2xxPDtNNYekNvG%2BABtzb9GtxuwrbfrBDMJXGVX9w%40mail.gmail.com>
Precedence: bulk

Op do 22 jan 2026 om 01:30 schreef Tatsuo Ishii <ishii@postgresql.org>:
>
> > Op wo 31 dec 2025 om 08:57 schreef Tatsuo Ishii <ishii@postgresql.org>:
> >> >> Unfortunately it's not possible to bind on all IP addresses for pgpool
> >> >> by tweaking hostnameN. You could specify it to '*' so that it binds on
> >> >> all IP addresses, but this will cause a different problem:
> >> >> communicating to other watchdog is refused. This is because each
> >> >> watchdog node name is created from hostnameN. If hostnameN is '*', the
> >> >> node name will be something like "*:5432 Linux..." which is different
> >> >> from what other watchdog nodes expect (they expect something like
> >> >> '172.29.30.1:5432 ...").
> >> >
> >> > I already suspected this. The same goes for using the actual docker
> >> > container ip, which is 172.29.29.107 on all 3 nodes. I think the best
> >> > solution would be to introduce a bind_address configuration parameter,
> >> > which defaults to hostnameN, but can be overridden. I guess the same
> >> > thing goes for heartbeat_hostnameN.
> >>
> >> Yeah, I thought the same. I will discuss with other developers next
> >> year.
> >>
> >> >> Since most pgpool developers are off for New Year's holiday, I will
> >> >> discuss them next week.
> >
> > Do you have an update on this already?
>
> I and Pengbo are discussing this off list. We are leaning towards
> adding "listen_addresses" like parameters as other parameters prefers
> "listen" over "bind" ("listen_addresses" and "pcp_listen_addresses").

That makes sense indeed.

> We are thinking to add:
> wd_listen_addresses0=''
> heartbeat_listen_addresses0=''
> :
> :
>
> because watchdog and hearbeat needs separate listen addresses
> parameter. So if we would add these parameters, users will need to
> configure number_of_watchdog_nodes * 2 parameters, which will be a
> pain.

I would expect to only have to configure 2 listen_addresses, because a
single instance only listens once per service (watchdog and
heartbeat). Is there a reason to have to configure the listen
addresses for all nodes on every node? Why does node 0 need to know
the listen address of nodes 1 and 2?

Isn't it possible to add the configuration like this:
wd_listen_address = '*'
wd_port = 9009
wd_heartbeat_listen_address = '*'
wd_heartbeat_port = 9694

I think it's also better to not assume the listen address and port are
identical to the address and port on which to connect. For example,
specific TCP forwarding rules might redirect traffic to entirely
different addresses and ports. So node 0 might listen at
192.168.3.50:10000, but TCP forwarding rules might require node 1 to
connect to 10.0.3.50:9009 to connect to node 0.

> One way to mitigate this is, to consider default values for these
> parameters if they are not specified.  There are two candidate for the
> default value.
>
> (1) "*"
>
> This is similar to the pre-4.7 behavior, but less secure.
>
> (2) same as hostname0 (for wd_listen_addresses0) and
>     heartbeat_hostname0 (for heartbeat_hostname0).
>
> This is current 4.7 behavior and more secure but does not work for
> your environment.
>
> What do you think?

I think, whatever implementation for the new parameters is chosen, the
default behavior or 4.7 should not change. So I'd go for option 2. I
don't mind having to change the configuration to get 4.7 working for
us, but I wouldn't expect a new version to be less secure by default
than the previous version was.

Best regards,
Emond