Thread

1. Feature: Use DNS SRV records for connecting

   Feike Steenbergen <feikesteenbergen@gmail.com> — 2019-08-13T09:50:18Z

   Hi all,
   
   I'd like to get some feedback on whether or not implementing a DNS SRV feature
   for connecting to PostgreSQL would be desirable/useful.
   
   The main use case is to have a DNS SRV record that lists all the possible
   primaries of a given replicated PostgreSQL cluster. With auto failover
   solutions like patroni, pg_auto_failover, stolon, etc. any of these endpoints
   could be serving the primary server at any point in time.
   
   Combined with target_session_attrs a connection string to a highly-available
   cluster could be something like:
   
      psql "dnssrv=mydb.prod.example.com target_session_attr=read_write"
   
   Which would then resolve the SRV record _postgresql._tcp.mydb.prod.example.com
   and using the method described in RFC 2782 connect to the host/port combination
   one by one until it finds the primary.
   
   A benefit of using SRV records would be that the port is also part of the DNS
   record and therefore a single IP could be used to serve many databases on
   separate ports. When working with a cloud environment or containerized setup
   (or both) this would open up some good possibilities.
   
   Note: We currently can already do this somehow by specifying multiple
   hosts/ports in the connection string, however it would be useful if we could
   refer to a single SRV record instead, as that would have a list of hosts
   and ports to connect to.
   
   DNS SRV is described in detail here:
   https://tools.ietf.org/html/rfc2782
   
   I'd love to hear some support/dissent,
   
   regards,
   
   Feike
   
   
   
   

2. Re: Feature: Use DNS SRV records for connecting

   Graham Leggett <minfrin@sharp.fm> — 2019-08-13T10:21:37Z

   On 13 Aug 2019, at 11:50, Feike Steenbergen <feikesteenbergen@gmail.com> wrote:
   
   > I'd like to get some feedback on whether or not implementing a DNS SRV feature
   > for connecting to PostgreSQL would be desirable/useful.
   
   A big +1.
   
   We currently use SRV records to tell postgresql what kind of server it is. This way all of our postgresql servers have an identical configuration, they just tailor themselves on startup as appropriate:
   
   _postgresql-master._tcp.sql.example.com.
   
   The above record in our case declares who the master is. If the postgresql startup says “hey, that’s me” it configures itself as a master. If the postgresql startup says “hey, that’s not me” it configures itself as a slave of the master.
   
   We also use TXT records to define the databases we want (with protection against DNS security issues, we never remove a database based on a TXT record, but signed DNS records will help here).
   
   _postgresql.sql.example.com TXT "v=PGSQL1;d=mydb;u=myuser"
   
   We use a series of systemd “daemons” that are configured to run before and after postgresql to do the actual configuration on bootup, but it would be great if postgresql could just do this out the box.
   
   Regards,
   Graham
   —
   
   

3. Re: Feature: Use DNS SRV records for connecting

   Tom Lane <tgl@sss.pgh.pa.us> — 2019-08-13T14:43:07Z

   Feike Steenbergen <feikesteenbergen@gmail.com> writes:
   > I'd like to get some feedback on whether or not implementing a DNS SRV feature
   > for connecting to PostgreSQL would be desirable/useful.
   
   How would we get at that data without writing our own DNS client?
   (AFAIK, our existing DNS interactions are all handled by getnameinfo()
   or other library-supplied functions.)
   
   Maybe that'd be worth doing, but it sounds like a lot of work and a
   lot of new code to maintain, relative to the value of the feature.
   
   			regards, tom lane
   
   
   
   

4. Re: Feature: Use DNS SRV records for connecting

   Andres Freund <andres@anarazel.de> — 2019-08-14T18:01:43Z

   Hi,
   
   On 2019-08-13 10:43:07 -0400, Tom Lane wrote:
   > How would we get at that data without writing our own DNS client?
   > (AFAIK, our existing DNS interactions are all handled by getnameinfo()
   > or other library-supplied functions.)
   
   > Maybe that'd be worth doing, but it sounds like a lot of work and a
   > lot of new code to maintain, relative to the value of the feature.
   
   It might have enough independent advantages to make it worthwhile
   though.
   
   Right now our non-blocking interfaces aren't actually in a number of
   cases, due to name resolution being blocking. While that's documented,
   it imo means that our users need to use a non-blocking DNS library, if
   they need non-blocking PQconnectPoll() - it's imo not that practical to
   just use IPs in most cases.
   
   We also don't have particularly good control over the order of hostnames
   returned by getaddrinfo, which makes it harder to implement reliable
   round-robin etc.
   
   Greetings,
   
   Andres Freund
   
   
   
   

5. Re: Feature: Use DNS SRV records for connecting

   Andrey Borodin <x4mmm@yandex-team.ru> — 2026-05-12T09:46:38Z

   Hi hackers!
   
   > On 22 Apr 2026, at 14:48, Andrey Borodin <x4mmm@yandex-team.ru> wrote:
   > 
   > I'm proposing this across the PostgreSQL driver ecosystem
   
   While preparing equivalent patches for pgx, pgjdbc and npgsql, Jack
   Christensen (pgx maintainer) raised a concern [0] about the
   postgres+srv:// URI scheme I proposed here.
   
   The issue is specific to Go's net/url package [1]. In Go 1.26 the URL
   parser was tightened and broke parsing of HA connection strings of
   the form postgresql://user@h1:1,h2:2/db (colons inside the authority
   after a comma). The Go team addressed this by relaxing validation,
   but only for the "postgres" and "postgresql" schemes - any new
   scheme, including "postgres+srv", gets the strict modern parser. For
   a single SRV name in the authority this is probably fine in practice,
   but Jack reasonably points out that deviating from postgresql:// is
   a compatibility bet without much upside. [2]
   
   Per RFC 3986 §3.1 the "+" in a scheme name is syntactically legal.
   Per RFC 7595 / BCP 35, schemes can be registered with IANA, but
   neither "postgresql" nor "mongodb+srv" is in the IANA registry today,
   so there is no formal gate to pass - just our own consensus on what
   to ship.
   
   On a related note, "mongodb", "redis" and "rediss" (Redis over TLS) are
   both registered with IANA as provisional schemes, while "mongodb+srv" is
   not - so there is no consistent precedent either way.
   
   Given the above, I see three options:
   
   1. Drop the +srv URI scheme entirely. Keep only the srvhost= keyword
      parameter. Smallest API surface, no compatibility concerns for
      any driver. No URI form to use DNS SRV at all.
   
        srvhost=cluster.example.com dbname=mydb target_session_attrs=read-write
   
   2. Keep postgresql+srv:// / postgres+srv:// as proposed. Aligns with
      the mongodb+srv:// precedent and reads naturally; a single cluster
      name in the authority is unaffected by Go's stricter parser, but
      driver authors take on a small risk for any future tightening.
   
        postgresql+srv://user@cluster.example.com/mydb?target_session_attrs=read-write
        postgres+srv://user@cluster.example.com/mydb
   
   3. Some other shorthand (pgsrv://). Avoids "+" entirely but invents
      yet another name with no clear advantage.
   
        pgsrv://user@cluster.example.com/mydb?target_session_attrs=read-write
   
   My slight preference is (1). The srvhost= parameter alone expresses
   intent unambiguously and avoids opening a second scheme namespace
   that every driver in the ecosystem would need to replicate.
   
   If we go with option (2), registering "postgresql+srv" as a
   provisional scheme with IANA (First Come First Served per RFC 7595
   §7.1) would take minimal effort and give the scheme a stable
   reference. Interestingly, even "postgresql" itself is not in the
   IANA registry despite being in use for over 20 years, so registration
   is not a prerequisite — but it would be a nice step toward treating
   SRV as a first-class URI scheme on par with mongodb+srv.
   
   On the other note "redis" and "rediss" are both provisioned with IANA.
   
   WDYT?
   
   
   Best regards,
   Andrey Borodin.
   
   [0] https://github.com/jackc/pgx/pull/2538
   [1] https://github.com/golang/go/issues/75859
   [2] https://github.com/jackc/pgx/issues/2404
   
   
   

6. Re: Feature: Use DNS SRV records for connecting

   Jacob Champion <jacob.champion@enterprisedb.com> — 2026-05-12T16:07:59Z

   Hello!
   
   I'm speaking only on the design questions here; I have not looked at
   the patch implementation yet.
   
   On Tue, May 12, 2026 at 2:47 AM Andrey Borodin <x4mmm@yandex-team.ru> wrote:
   > While preparing equivalent patches for pgx, pgjdbc and npgsql, Jack
   > Christensen (pgx maintainer) raised a concern [0] about the
   > postgres+srv:// URI scheme I proposed here.
   >
   > The issue is specific to Go's net/url package [1]. In Go 1.26 the URL
   > parser was tightened and broke parsing of HA connection strings of
   > the form postgresql://user@h1:1,h2:2/db (colons inside the authority
   > after a comma). The Go team addressed this by relaxing validation,
   > but only for the "postgres" and "postgresql" schemes - any new
   > scheme, including "postgres+srv", gets the strict modern parser. For
   > a single SRV name in the authority this is probably fine in practice,
   > but Jack reasonably points out that deviating from postgresql:// is
   > a compatibility bet without much upside. [2]
   
   So this doesn't answer your broader question, really, but I consider
   it a Very Good Thing that Go is enforcing stricter validation. If we
   choose to introduce a brand-new scheme, I think we should do it by the
   book and not carry over our oddities from 2012.
   
   > Per RFC 3986 §3.1 the "+" in a scheme name is syntactically legal.
   > Per RFC 7595 / BCP 35, schemes can be registered with IANA, but
   > neither "postgresql" nor "mongodb+srv" is in the IANA registry today,
   > so there is no formal gate to pass - just our own consensus on what
   > to ship.
   >
   > On a related note, "mongodb", "redis" and "rediss" (Redis over TLS) are
   > both registered with IANA as provisional schemes, while "mongodb+srv" is
   > not - so there is no consistent precedent either way.
   
   As a continuation of the above, I think it'd be good to ask for IETF
   review on any new scheme. The [scheme]+[variant]: form has some
   uptake, but there are also expert reviewer notes saying that some
   attempts might make things difficult for implementers (or others in
   the ecosystem).
   
   > Given the above, I see three options:
   >
   > 1. Drop the +srv URI scheme entirely. Keep only the srvhost= keyword
   >    parameter. Smallest API surface, no compatibility concerns for
   >    any driver. No URI form to use DNS SRV at all.
   
   Either way, we'll need to define the semantics of mixing this new mode
   with the existing parameters. I think that's likely to introduce its
   own subtle compatibility concerns if we don't design it up front.
   
   (Your proposal doesn't introduce this problem, but we never should
   have allowed query parameters to modify the prior components --
   scheme, authority, path -- of the URI. I am strongly motivated to fix
   that, though I don't really want to derail SRV conversations too much
   with it.)
   
   > 2. Keep postgresql+srv:// / postgres+srv:// as proposed. Aligns with
   >    the mongodb+srv:// precedent and reads naturally; a single cluster
   >    name in the authority is unaffected by Go's stricter parser, but
   >    driver authors take on a small risk for any future tightening.
   
   Can you elaborate on the additional risk?
   
   IMO, if a URI identifies a single resource (the cluster), it doesn't
   seem like anyone needs to support our comma pseudo-syntax anymore.
   Drivers that want to connect to multiple clusters can take multiple
   fully formed URIs, and define how to configure that in a way that
   makes sense for them.
   
   > 3. Some other shorthand (pgsrv://). Avoids "+" entirely but invents
   >    yet another name with no clear advantage.
   >
   >      pgsrv://user@cluster.example.com/mydb?target_session_attrs=read-write
   
   I guess I don't see what this accomplishes. The `+` is not the problem, right?
   
   --
   
   I would additionally propose options 4 and 5 (which you don't need to
   feel obligated to give any thought to):
   
   4. Use the new behavior opportunistically somehow, similar to how
   https: has continued to evolve the underlying protocol and DNS lookup
   without any scheme changes at all. Whether this is technically
   feasible without usability and security concerns... I don't know at
   this point.
   
   5. Moonshot: break compatibility outright, and design a scheme that
   does exactly what we want in 2026. Strong URI semantics, enforcement
   of TLS, useful DNS semantics, etc., etc. Represents complete
   derailment of the thread. :)
   
   Thanks,
   --Jacob
   
   
   
   

7. Re: Feature: Use DNS SRV records for connecting

   Zsolt Parragi <zsolt.parragi@percona.com> — 2026-05-12T21:05:45Z

   Hello!
   
   Shouldn't srvhost be freed in freePGconn?
   
   + /*
   + * If srvhost is set, validate mutual exclusivity with host/hostaddr and
   + * then resolve _postgresql._tcp.<srvhost> SRV records, populating
   + * conn->pghost and conn->pgport from the sorted results.  This must
   + * happen before the host-array allocation below.
   + */
   + if (conn->srvhost != NULL && conn->srvhost[0] != '\0')
   
   Shouldn't this also cover port? The current behavior with it seems inconsistent.
   
   > The resolved host list is sorted per RFC 2782 and injected into the
   > existing multi-host machinery before connhost[] is built, so
   > target_session_attrs, load_balance_hosts, and failover work on the
   > expanded list without any changes to PQconnectPoll.
   
   Doesn't RFC 2782 specifies a weighted random selection? The current
   code seems to be deterministically sorted by weight.
   RFC also says that weight=0 should be specially handled, it provides a
   detailed algorithm about the random selection method.