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

On Wed, Mar 25, 2026 at 7:24 AM Andrew Jackson
<andrewjackson947(at)gmail(dot)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/