| 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
| 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 |