Thanks for the pointer to patch 5396 - I wasn't aware of Andrew Jackson's prior work on this. I'd also like to add another argument from that thread. Artem Navrotskiy pointed out [1] that the current behavior actually contradict the documentation. The libpq docs [2] state: "When multiple hosts are specified, or when a single host name is translated to multiple addresses, all the hosts and addresses will be tried in order, until one succeeds." The current behavior where target_session_attrs mismatch skips remaining addresses doesn't match this. A standby successfully responding but not matching target_session_attrs isn't a "connection failure" per se, but it does prevent finding a "successful" connection according to the user's requirements. This suggests the simpler fix might actually be correcting a deviation from documented behavior, rather than introducing new behavior requiring a new parameter (as in 5396). Happy to coordinate with Andrew on this - perhaps the question is whether this should be:
1. A behavioral fix which matches documentation 2. An opt-in feature (5396's check_all_addrs parameter) - preserves backward compatibility Given the documentation wording, I'd lean toward (1), but curious what others think. [1] https://www.postgresql.org/message-id/[email protected] [2] https://www.postgresql.org/docs/current/libpq-connect.html#LIBPQ-MULTIPLE-HOSTS Thanks, Evgeny ________________________________ From: Andrey Borodin <[email protected]> Sent: Thursday, March 5, 2026 3:16 PM To: Tom Lane <[email protected]> Cc: Evgeny Kuzin <[email protected]>; [email protected] <[email protected]> Subject: Re: [PATCH] libpq: try all addresses for a host before moving to next on target_session_attrs mismatch > On 5 Mar 2026, at 19:55, Tom Lane <[email protected]> wrote: > > TBH, I'd say that your DNS setup is broken and you should fix it. > It makes no sense to have the same DNS entry pointing to both > read-write and read-only hosts. The proposed patch will mainly > result in useless connection attempts in more-sanely-constructed > setups. This is very desired feature by cloud providers. We sell PGaaS clusters which are just a bunch of hosts. Each of these hosts can became primary any time. Currently, when user adds more hosts they have to redeploy\reconfigure their app. Unless user uses pgx that already works this way, then we can just give them one FQDN for whole cluster and update DNS records. This was proposed before [0] and I think Andrew and Evgeny could join efforts. Certainly, this can be implemented without affecting those who do not need it. Best regards, Andrey Borodin. [0] https://commitfest.postgresql.org/patch/5396/
