On Thu, Mar 12, 2026 at 2:22 PM Zsolt Parragi <[email protected]> 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/
