> 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
