Jacob, I appreciate that Evgeny and myself are trying to introduce patches that, while seemingly simple, have stumbled on a bunch of complexities (what is a host? how does libc handle address lookup?, etc) that may not make our patches the ideal long term solution for the problem at hand. I'm thinking that maybe it is worthwhile to take a step back at the problem that we are trying to solve to see if there are any alternative approaches that would be easier to merge in the medium term.
Problem: I would like to make it easier for managed service operators to allow client side auto discovery/failover by providing a single place where the managed service operator can change connection parameters so that end users don't need to update their connection parameters which may be hardcoded, not source controlled, in excel spreadsheets, etc. IE managed service providers should be able to provide a connection string to customers that does not hardcode a list of hosts as this is subject to change as nodes get added, removed, moved, etc. Currently the closest thing to this that exists in libpq is libpq's "LDAP Lookup of Connection Parameters" functionality. One issue with this functionality that I see is that it can only be used with the pg_service.conf file and cannot be provided in a connection string. There is a very (37 lines of code) small patch [1] that adds this ability and would make "LDAP Lookup of Connection Parameters" far more accessible in my opinion. One downside with the LDAP functionality is that many database teams do not have the ability to dynamically change their organizations LDAP records. An alternative that I have a very rough patch for is using the addition of libcurl to enable connection parameters to be looked up at an HTTP address. This is a much larger patch than the LDAP one and is probably more controversial so understood if this is not going to make it in the medium term (or ever). Also thank you for your review in this thread. Definitely learned a lot from that. Thanks, Andrew Jackson [0]: https://www.postgresql.org/docs/current/libpq-ldap.html [1]: https://commitfest.postgresql.org/patch/6390/ [2]: https://commitfest.postgresql.org/patch/6614/ On Wed, Mar 25, 2026 at 8:13 AM Jacob Champion <[email protected]> wrote: > > 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 > > > >
