Giters

jackc / pgconn

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

ConnectConfig doesn't return the underlying PG error when there are fallback configs

leungster opened this issue · comments

commented

I noticed this regression when upgrading from 1.8.0 to 1.8.1+

This block of code shortcircuits fallback evaluation for specific PG errors. Prior to this change, it would shortcircuit on the first PG error it encountered by returning the connectError.
If there's any other PG error such as InsufficientPrivilege: 42501, it'll run through the fallback IPs and return the last error.

For my case, I'm connecting as localhost which expands to IPv4 and IPv6 fallback configs. If my postgres server isn't listening on one of those IPs, then the last connection error is returned. Since my postgres server isn't listening to one of these IP ranges, I'm receiving a network is unreachable instead of the underlying PG error from the first connection attempt.
In my case, I'm checking the PG error codes to increase privileges for users that are having trouble connecting.

commented

IIRC, the idea behind that code case was to match the behavior of https://www.postgresql.org/docs/current/libpq-connect.html#LIBPQ-MULTIPLE-HOSTS.

If a connection is established successfully, but authentication fails, the remaining hosts in the list are not tried.

I would have expected 42501 to be an authorization error, not an authentication error.

Are you getting InsufficientPrivilege: 42501 as part of the connection process or is that being triggered by a ValidateConnect hook?

Also, what is the behavior of psql / libpq?

Depending on that I guess there are two considerations. 1. If error 42501 should be considered an error that cancels future callbacks. 2. If the fallbacks should preserve the first error they encounter (or maybe just the first PG error...)

commented

I think this is a special case because the 42501 is for the CONNECT privilege on the target DB.
With psql it'll shortcircuit and not try another host.

commented

I just added 42501 to the list of error codes which terminate the connection attempt. This should resolve the issue and closer match libpq behavior.