-
Notifications
You must be signed in to change notification settings - Fork 181
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
async connection API does not properly handle timeouts with multiple hosts #618
Comments
pg-1.5.x versions should do proper connection timeout handling. The details are described in this commit: 40b2ad5 In your case it should wait 5 seconds per connection and abort after 10 seconds if no connection can be established. Can you describe how it behaves in your setup? Can you do a bit debugging in the code path of pg that you referenced, to investigate how it behaves exactly? |
Its not, here an example: Run a postgres docker:
This test program
Set PGHOST (10.0.0.1 is just some address to which a connection will timeout):
The expected behavior is the connection to 10.0.0.1 times out after 5 seconds but the client connection to 127.0.0.1 succeeds. Instead you can see the connection simply times out after 5 seconds. Here is a PR with what I think the correct behavior should be: #619 |
If 10.0.0.1 does not respond via TCP even if 10.0.0.2 is online and functioning the following connection will timeout
The issue is that the async api supported by libpq ignores the "connect_timeout" connection parameter when using PQconnectStart/PQconnectPoll:
The connect_timeout connection parameter is ignored when using PQconnectPoll; it is the application's responsibility to decide whether an excessive amount of time has elapsed.
You can see discussion of this on the PostgreSQL hackers mailing list. Specifically around this same issue with psycopg3.
Browsing the code a bit I believe when the connect_timeout expires here rather then failing there needs to be a call to PQreset or PQresetStart/PQresetPoll to force libpq to reset the connection and try to access the next host?
The text was updated successfully, but these errors were encountered: