Hi Evgeny, (Evgeny asked me to weigh in on the patch. Careful what you wish for...)
I would like to, as kindly as possible, say that I don't like *either* of these approaches, on this thread or the other. General concerns up front: - A read-only host and a read-write host aren't the "same host". `target_session_attrs=any` doesn't work for your case *because* they're not. Our protocol, and the applications on top of it, do not consider them interchangeable. (You can maybe argue that multiple read-only hosts could be treated as one, and I think I'd agree -- but the proof of that is, round-robin DNS already works in that case. Right?) - Is POSIX getaddrinfo *guaranteed* to return every record, on all platforms? It's not a DNS-specific API, so what's preventing a libc from omitting the single read-write IP address you need out of a group of twenty because [insert POSIX-allowed or IETF-mandated reason]? - I'm no DNS expert, but I can't shake the feeling that you're (mis)using round-robin A records to reimplement, say, SRV records [1] (or SRVB, which dovetails with recently-standardized ECH). On Wed, Mar 11, 2026 at 7:29 AM Evgeny Kuzin <[email protected]> wrote: > A refinement: what if we only change behavior when target_session_attrs is > explicitly set to something other than any? The logic would be: > > target_session_attrs=any (default): current behavior unchanged > target_session_attrs=read-write/primary/standby/etc: iterate all addresses on > mismatch Users should not have to choose between a) target_session_attrs fallback and b) reasonable and performant behavior with modern hybrid-stack/multi-NIC/multihomed/etc. setups. I think you've tangled a Postgres-level concern (find me a host with these characteristics) with a socket-level concern (find me the addresses for a host), and the main reason you were able to do that was because PQconnectPoll() currently puts all those concerns into one impossibly complex function. If someone later wanted to replace getaddrinfo/connect with a Happy Eyeballs library, to cut down on connection times, this proposal would prevent them from doing that. (Both your patch, and the other thread's.) Personally I think we should reserve the ability to use any API that says "connect me to this hostname as fast as possible; I do not care how." > I just want to find whichever approach has the best chance of actually > getting accepted, rather than having a good feature sit in review for another > year. The bar for getting something into a release can (sometimes? often?) be too high, for the wrong reasons, especially for a new contributor. I don't want to make that problem worse; I'm very glad you're here and focusing on this use case. But I don't think you should expect either patch to make it into PG19 in the middle of March, unless you've already found another committer who's willing to maintain them. I understand why it's appealing, I think, but the discussions so far on both threads don't convince me that this is an overall reduction of complexity. It exposes more implementation details, which makes it harder to improve our network connection behavior in the future. It potentially collides with attempts to encode network topology within the Postgres protocol. I don't think we're likely to be happy with it in a few years. But I do want you to be able to point libpq at a cluster and have it Just Work. It's a good conversation to have, even if this doesn't make it in. --Jacob [1] https://postgr.es/m/CAK_s-G2_3S09_EA%2BnRxxefMW%2B0-UwKE%3DUj6bCdBpPncPVRpM_g%40mail.gmail.com
