Remove assumption that the auth response is AuthenticateOk#1188
Merged
arp242 merged 1 commit intolib:masterfrom Jan 24, 2026
Merged
Remove assumption that the auth response is AuthenticateOk#1188arp242 merged 1 commit intolib:masterfrom
arp242 merged 1 commit intolib:masterfrom
Conversation
388e66a to
ca66dd0
Compare
Collaborator
|
It would be great to have some tests for this. I added pgpool to the CI with #1218, but unfortunately this entire auth() function is never tested at the moment (code is always 0). |
arp242
added a commit
that referenced
this pull request
Jan 10, 2026
Doesn't run all the tests, even though they work fine locally? https://github.com/lib/pq/actions/runs/20829056100/job/59993754645 Although even locally it's not completely "fine" because tests start failing after a few test runs for some reason. I added pgpool for #1188, but It's an old container with an old version, and I have the impression it's not that widely used (there's no package on Void for example). I'm going to say that people who want pgpool support can send a PR to properly fix it.
arp242
added a commit
that referenced
this pull request
Jan 10, 2026
Doesn't run all the tests, even though they work fine locally? https://github.com/lib/pq/actions/runs/20829056100/job/59993754645 Although even locally it's not completely "fine" because tests start failing after a few test runs for some reason. I added pgpool for #1188, but It's an old container with an old version, and I have the impression it's not that widely used (there's no package on Void for example, and #1188 and #342 are the only two mentions in 14 years of pq). I'm going to say that people who want pgpool support can send a PR to properly fix it.
arp242
added a commit
that referenced
this pull request
Jan 10, 2026
Doesn't run all the tests, even though they work fine locally? https://github.com/lib/pq/actions/runs/20829056100/job/59993754645 Although even locally it's not completely "fine" because tests start failing after a few test runs for some reason. I added pgpool for #1188, but It's an old container with an old version, and I have the impression it's not that widely used (there's no package on Void for example, and #1188 and #342 are the only two mentions in 14 years of pq). I'm going to say that people who want pgpool support can send a PR to properly fix it.
ca66dd0 to
8c9dbb0
Compare
pq currently assumes the message sent from the server after sending PasswordMessage to be AuthenticationOk. However, this assumption doesn't always stand as the server may send some other messages other than AuthenticationOk such as another authentication request. That occurs when lib/pq is trying to connect to a PgPool-II server, where the following procedure is required as PgPool-II wants to have the password in both Cleartext and MD5 formats: [Client -> Server] StartupMessage [Server -> Client] AuthenticationCleartextPassword [Client -> Server] PasswordMessage [Server -> Client] AuthenticationMD5Password [Client -> Server] PasswordMessage [Server -> Client] AuthenticationOk [Server -> Client] ReadyForQuery Current implementation of auth function of pq will fail if the message after sending credentials is not AuthenticationOk, but we can just return before checking it and let another loop of auth check it instead. libpq does support handling multiple authentication requests, thus it can connect to PgPool-II just fine with the procedure above. So making pq check the message sent from the server after PasswordMessage will solve the described issue and align its behavior with the official client.
8c9dbb0 to
af1398d
Compare
Collaborator
|
Added tests in #1222. |
Contributor
Author
|
@arp242 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR aims to solve an issue where lib/pq fails to connect to a PostgreSQL cluster via PgPool-II.
Issue description
lib/pq currently assumes the message sent from the server after sending PasswordMessage to be AuthenticationOk.
However, this assumption doesn't always stand as the server may send some other messages other than AuthenticationOk such as another authentication request.
That occurs when lib/pq is trying to connect to a PgPool-II server, where the following procedure is required as PgPool-II wants to have the password in both Cleartext and MD5 formats:
[Client -> Server] StartupMessage
[Server -> Client] AuthenticationCleartextPassword
[Client -> Server] PasswordMessage
[Server -> Client] AuthenticationMD5Password
[Client -> Server] PasswordMessage
[Server -> Client] AuthenticationOk
[Server -> Client] ReadyForQuery
Solution description
Current implementation of auth function of lib/pq will fail if the message after sending credentials is not AuthenticationOk, but we can just return before checking it and let another loop of auth check it instead.
The official client libpq (and of course softwares that use it such as psql and pgAdmin) does support handling multiple authentication requests, thus it can connect to PgPool-II just fine with the procedure above. So making lib/pq check the message sent from the server after PasswordMessage will solve the described issue and align its behavior with the official client.
Thank you for checking out this PR. Please let me know if there's anything that is missing or needs improvements with this PR.