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

From: Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>
To: Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>
Cc: Evgeny Kuzin <evgeny(dot)kuzin(at)outlook(dot)com>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: [PATCH] libpq: try all addresses for a host before moving to next on target_session_attrs mismatch
Date: 2026-05-12 20:38:30
Message-ID: CAOYmi+niURLWTXKXvb8yQPHy1gHO2JqQXKYopWj3N9TzzsfsEw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Mar 12, 2026 at 2:22 PM Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)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/

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jacob Champion 2026-05-12 20:48:03 Re: [PATCH] libpq: try all addresses for a host before moving to next on target_session_attrs mismatch
Previous Message Nathan Bossart 2026-05-12 20:34:18 Re: FOR PORTION OF does not recompute GENERATED STORED columns that depend on the range column