-
Notifications
You must be signed in to change notification settings - Fork 860
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Timeout error not show which fallback was used #1942
Comments
Fixes: jackc#1942 Once we face a timeout we should expose address, it can be for example ipv6 or ipv4 and knowing what exact address we took for resolver extreamly helpful for triaging a networking issue. This issue is also fixed in pgx/v4, see: jackc/pgconn#139
I think this is fundamentally the same issue as #1929. And I think it should be solved by the same approach. |
This error is an exception, so solving same way as #1929 - is incorrect, since we try host sequential, once we reach first timeout all other host will receive same errTimeout automatically. |
In the meantime using parallel conn checker would break dual-stack logic. I tried to implement parallel connect. In this approach we will use the ipv4 address and start working with it, so in theory it's okay, but the |
Nah, multiple errors would be equal to no error, you will see 2 hosts that errored but in fact only one is not reachable. |
FWIW, multi errors are implemented in 8db9716. This will produce errors like:
|
This is a bit wrong, per what I see in commit, what happens when ipv4 connectivity is ok, but ipv6 is blocked is an issue. |
If ipv4 worked then no error would be returned. The error list is only returned if no attempt succeeds. |
Then this violate original behavior of ip versions priority, for example psql cli (and any known to me driver) will ignore ipv4 if ipv6 available on host, so connecting here would be a strange behavior. |
This is matching the behavior of libpq. See https://www.postgresql.org/docs/current/libpq-connect.html#LIBPQ-MULTIPLE-HOSTS.
This is exactly what pgx is trying to match. Furthermore, there is no change in connection behavior. The only change 8db9716 made was to report the results of all attempts when none of them succeeded. |
Then looks like this closes the original issue. Enviroment:
With incorrect db-name error is not network related:
With correct DB URL:
|
@jackc will you backport this to old v4 driver? (some people still use it, for example me :D) |
Personally, I don't plan on porting back to v4. I'm not sure how far that part of the code has diverged between v4 and v5 and I'm typically only doing bug fixes on v4. But if someone else wants to do the work I don't mind merging it. |
Okay, I'll try to backport and if it goes well - will open PR. |
Is your feature request related to a problem? Please describe.
Same as here: jackc/pgconn#139
Given: Cluster with ipv4 and ipv6 address.
when there is no network connection we should see what exact address we failed to connect
Describe the solution you'd like
Show IP-address that failed as part of error message.
Describe alternatives you've considered
Leave it as is
Additional context
This error also fixed at v4 driver - jackc/pgconn#140
The text was updated successfully, but these errors were encountered: