Re: [PATCH] libpq: try all addresses for a host before moving to next on target_session_attrs mismatch

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/235381750793454@mail.yandex.ru
[2] https://www.postgresql.org/docs/current/libpq-connect.html#LIBPQ-MULTIPLE-HOSTS
Thanks,
Evgeny

________________________________
From: Andrey Borodin <x4mmm(at)yandex-team(dot)ru>
Sent: Thursday, March 5, 2026 3:16 PM
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Evgeny Kuzin <evgeny(dot)kuzin(at)outlook(dot)com>; pgsql-hackers(at)lists(dot)postgresql(dot)org <pgsql-hackers(at)lists(dot)postgresql(dot)org>
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 <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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/