Thread

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

Jacob Champion <jacob.champion@enterprisedb.com> — 2026-05-12T20:38:30Z

On Thu, Mar 12, 2026 at 2:22 PM Zsolt Parragi <zsolt.parragi@percona.com> wrote:
> The cluster knows its topology, from it's own viewpoint. Standby
> saying "primary is at 10.0.0.42:5432" isn't helpful to the client,
> proxies exist.

I think the idea of having a newly promoted/demoted node redirect a
client to the proper place has merit, regardless of how the IPs are
looked up initially.

> Aren't these just variations to the same question? Which IPs to try to
> connect, in which order/parallelism?
>
> In a happy eyeballs analogy, one approach might want to connect to all
> listed IPs at the same time, and return the first that responds and is
> read write.

Once you tack "and is read-write" onto that list, you've coupled the
application semantics into the IP lookup, and then it's very
fundamentally not the same question.

I'm not saying "don't answer that question". But I am strongly
suggesting that we not answer it by messing around with the definition
of "host" and making a bunch of potentially unfounded assumptions on
how getaddrinfo() is going to work. Choose a way that doesn't preclude
the use of connect-by-name APIs [1] for the simple non-cluster case.

(Looks like Happy Eyeballs v3 [2] is taking a look at the interaction
with SVCB records, which again makes me feel like we should be staring
very intently at what the browsers are doing.)

Thanks,
--Jacob

[1] https://www.ietf.org/proceedings/72/slides/plenaryw-6.pdf p. 31
[2] https://datatracker.ietf.org/doc/draft-ietf-happy-happyeyeballs-v3/03/