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

From: Evgeny Kuzin <evgeny(dot)kuzin(at)outlook(dot)com>
To: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "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-03-11 14:29:39
Message-ID: AM9PR09MB4900179BE474DCA727B73C479747A@AM9PR09MB4900.eurprd09.prod.outlook.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> One example of what Tom worries about is "localhost" resolving to both "127.0.0.1" and "::1",
> a very common case. With the proposed change, any connection attempt to "localhost" that fails
> would now take twice as long to fail. Also, if the problem is authentication, the server would
> perform two authentication attempts. That is a clear regression that may affect many people.
>
> The question is whether the overall benefits of your proposal (which certainly makes sense
> in a setup like you describe) would be worth a performance and resource usage regression like
> the one I described above. Or can you see a way to modify your approach so that that problem
> can be avoided?

Good point about the localhost regression. I agree that changing default behavior might not be the right approach.
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

In the explicit role-aware routing case, the user is already saying "I need a specific type of server" - so probing multiple addresses is the expected behavior. It's similar to specifying host=pg1,pg2,pg3 manually.
This would address the localhost concern while enabling the HA use case for those who explicitly opt in via target_session_attrs.
The question becomes: is this a cleaner approach than a separate check_all_addrs parameter (patch 5396)? It's opt-in either way, but this ties the behavior to the feature that actually needs it.
That said, I'm happy either way - if the consensus is that 5396's explicit parameter is the better path, that works for me too. It solves the same problem. 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.
Best regards,
Evgeny

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bertrand Drouvot 2026-03-11 14:44:11 Make Intel's ICX compiler working
Previous Message Alexander Korotkov 2026-03-11 14:24:05 Re: Exit walsender before confirming remote flush in logical replication