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