public inbox for [email protected]
help / color / mirror / Atom feedFrom: Emond Papegaaij <[email protected]>
To: Tatsuo Ishii <[email protected]>
Cc: [email protected]
Subject: Re: Pgpool-II 4.7.0 released.
Date: Thu, 22 Jan 2026 11:05:20 +0100
Message-ID: <CAGXsc+Yg8Y2xxPDtNNYekNvG+ABtzb9GtxuwrbfrBDMJXGVX9w@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <CAGXsc+ZM=aE=ibSDintubM8Ni8kfeaXK963Xca05j-SBYLPhhA@mail.gmail.com>
<[email protected]>
<CAGXsc+au8Wzjsuk1z-mqPFLfpkjQZSPneLLVbnkUs5rAMXNF=A@mail.gmail.com>
<[email protected]>
Op do 22 jan 2026 om 01:30 schreef Tatsuo Ishii <[email protected]>:
>
> > Op wo 31 dec 2025 om 08:57 schreef Tatsuo Ishii <[email protected]>:
> >> >> 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
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected]
Subject: Re: Pgpool-II 4.7.0 released.
In-Reply-To: <CAGXsc+Yg8Y2xxPDtNNYekNvG+ABtzb9GtxuwrbfrBDMJXGVX9w@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox