Thread

1. 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:12:54Z

   On Thu, Mar 12, 2026 at 3:43 AM Evgeny Kuzin <evgeny.kuzin@outlook.com> wrote:
   > > 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
   >
   > Would reviving SRV support be a direction you'd consider architecturally sound?
   
   I'm, again, no DNS expert. But I think we'd be moving in the same
   direction as other cluster-aware software if we explored that
   approach, which feels reasonable to me.
   
   > Another thought - what about cluster-aware routing at the protocol level? A standby could redirect to the primary - similar to HTTP 302. The cluster knows its own topology, libpq stays fast and dumb about it. That would preserve the "connect me as fast as possible" ability you mentioned. Though that feels like a bigger architectural lift compared to SRV.
   
   I think there might be a good argument for having both. Topologies
   aren't static; ideally you want your client to navigate a failover
   successfully, but you probably don't want to *optimize* for constant
   failovers.
   
   --Jacob
   
   
   
   

2. 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:15:12Z

   On Thu, Mar 12, 2026 at 9:01 AM Alastair Turner <minion@decodable.me> wrote:
   > Administering A records with multiple IP addresses is also a simpler, flat process.
   
   I agree, but I'm arguing that this architectural simplicity is also
   architecturally unsound.
   
   > I'd say that the boundary has moved - from "find me an endpoint from this list of hosts with these characteristics" to "find me an endpoint from this list of IPs with these characteristics" - rather than that they've become tangled. "Connect me to this list of addresses as fast as possible" still sounds like a good place to be.
   
   I'm uncomfortable redefining "host" in our code as a bag of arbitrary
   unrelated IP addresses.
   
   Here are some similar feature requests, adjusted to be more obviously
   problematic IMO, which should hopefully give you heartburn.
   
   - "I want libpq to try the next IP address if I try to connect to
   example.net and it gives me a certificate for evil.example.com."
   - "Ditto, if the certificate chain I'm served is completely invalid."
   - "Ditto, if the server cert is valid but it doesn't speak the postgresql ALPN."
   
   These are all indications that something is dangerously wrong with the
   entire *host*, and I think we should not continue in any of those
   cases.
   
   --Jacob
   
   
   
   

3. 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/
   
   
   
   

4. 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:48:03Z

   On Thu, Mar 12, 2026 at 2:43 PM Greg Sabino Mullane <htamfids@gmail.com> wrote:
   > I'm still a big +1 to the original proposal in this thread, and don't think it would be incompatible with happy eyeballs. Although I would think the latter would be quite wasteful, as we are not simply checking for a response, but doing a whole connect/authenticate/get-status dance.
   
   Just to make it clear, this is the opposite of what I'm arguing for.
   Happy Eyeballs implementations should not couple to application-level
   concerns, and we should not have to open up a bazillion concurrent
   connections just to find the single read/write leader.
   
   --Jacob
   
   
   
   

5. 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-12T21:20:25Z

   On Wed, Mar 25, 2026 at 7:24 AM Andrew Jackson
   <andrewjackson947@gmail.com> wrote:
   > 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.
   
   Agreed. I would like libpq to support this case, and I think Postgres
   users who are not managed service providers would find benefits in it
   too.
   
   > 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.
   
   My shortest take is that I think we should avoid building new
   infrastructure on top of unauthenticated LDAP.
   
   > 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).
   
   Going back to my statement way above: I still feel like this is
   reinventing pieces of DNS. Quoting from the SVCB spec [1]:
   
      The goal of the SVCB RR is to allow clients to resolve a single
      additional DNS RR in a way that:
   
      *  Provides alternative endpoints that are authoritative for the
         service, along with parameters associated with each of these
         endpoints.
   
      *  Does not assume that all alternative endpoints have the same
         parameters or capabilities, or are even operated by the same
         entity.  This is important, as DNS does not provide any way to tie
         together multiple RRsets for the same name.  For example, if
         "www.example.com" is a CNAME alias that switches between one of
         three Content Delivery Networks (CDNs) or hosting environments,
         successive queries for that name may return records that
         correspond to different environments.
   
      *  Enables CNAME-like functionality at a zone apex (such as
         "example.com") for participating protocols and generally enables
         extending operational authority for a service identified by a
         domain name to other instances with alternate names.
   
   Doesn't that sound like exactly what we want?
   
   > Also thank you for your review in this thread. Definitely learned a
   > lot from that.
   
   You're welcome! Thanks for your patience while I typed this up.
   
   --Jacob
   
   [1] https://datatracker.ietf.org/doc/rfc9460/
   
   
   
   

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

   Evgeny Kuzin <evgeny@hudson-trading.com> — 2026-05-23T19:05:58Z

   I spent some more time digging into this to make sure I was not overlooking something fundamental in the resolver behavior here.
   
   I agree that POSIX does not specify getaddrinfo() as a dns rrset api. It is a socket address selection api, and the specification leaves room for address family filtering, ordering, mapped addresses, AI_ADDRCONFIG, and other system policy decisions [1].
   
   But I think there is an important distinction between:
   
   - getaddrinfo() is not specified to preserve exact DNS semantics
   - getaddrinfo() will normally lose arbitrary dns answers
   
   The second conclusion does not seem to follow from the first one.
   
   In the specific A/AAAA case discussed here, the linux libc implementations I checked generally do expose the full usable RRset returned by the resolver unless there is an explicit policy reason not to (AI_ADDRCONFIG, v4mapped handling, requested address family, resolver policy, etc).
   
   This behavior is also consistent with dns resolver semantics themselves. Rfc1035 defines truncation handling via the TC bit, and rfc1123 requires retrying over tcp when truncation occurs [2][3]. In the ordinary dns case, I would therefore not expect a conforming resolver stack to silently hand libc an arbitrary partial RRset.
   
   The cases where getaddrinfo() may legitimately omit addresses are mostly the same cases where connection behavior is already policy-sensitive anyway:
   
   - mixed ipv4/v6 environments
   - AI_ADDRCONFIG filtering
   - v4mapped handling
   - resolver policy rules
   - non dns nss sources
   
   Those are not really random losses of dns data. They are explicit host resolution and connectivity policy decisions.
   
   What concerns me more about introducing a dns client inside libpq is that we would no longer be following the same resolver path as the rest of the system. That is user-visible behavior, not merely an implementation detail.
   
   For example, it risks bypassing or changing behavior around:
   
   - /etc/hosts
   - nsswitch.conf
   - mdns
   - ldap integration
   - systemd-resolved policy
   - split dns
   - vpn-specific resolver routing
   - container/runtime-specific resolution
   
   The current behavior may not be theoretically perfect from a dns abstraction perspective, but it is operationally well-understood and consistent with existing unix networking expectations.
   
   My concern is that we may be trading a relatively narrow theoretical weakness in the getaddrinfo() contract for a much broader compatibility and behavioral change in existing deployments.
   
   [1] https://pubs.opengroup.org/onlinepubs/9799919799/functions/getaddrinfo.html
   [2] https://datatracker.ietf.org/doc/html/rfc1035
   [3] https://datatracker.ietf.org/doc/html/rfc1123#section-6.1.3.2