Update max_protocol_version and min_protocol_version defaults#2526
Open
abrightwell wants to merge 1 commit intojackc:masterfrom
Open
Update max_protocol_version and min_protocol_version defaults#2526abrightwell wants to merge 1 commit intojackc:masterfrom
max_protocol_version and min_protocol_version defaults#2526abrightwell wants to merge 1 commit intojackc:masterfrom
Conversation
When `max_protocol_version` is not explicitly set, the default value is set to "3.0". This is reasonable and is inline with the same behavior as libpq[1]. Though, what libpq attempts to do that was not being done here is to reasonably upgrade or auto-raise the value of `max_protocol_version` when it has not been explicitly set. Here, we're providing the same functionality. In libpq, this determination is based on the parsed config values. We do the same here, parsing the values in ParseConfig to validate and determine the appropriate default for max_protocol_version. The string fields on Config are then set accordingly, and re-parsed at connection time as before. After parsing, when `max_protocol_version` has not been explicitly set, if `min_protocol_version` is greater than 3.0, `max_protocol_version` defaults to `latest`; otherwise it defaults to 3.0 for compatibility with older servers/poolers that don't support NegotiateProtocolVersion. [1] postgres/postgres@285613c
5f6ed71 to
2f81f1f
Compare
abrightwell
commented
Mar 26, 2026
| const ( | ||
| ProtocolVersion30 = 196608 // 3.0 | ||
| ProtocolVersion32 = 196610 // 3.2 | ||
| ProtocolVersionLatest = ProtocolVersion32 // Latest is 3.2 |
Contributor
Author
There was a problem hiding this comment.
Not necessary for this change. But as I was working through attempting to remove the double-parse requirement, I had added it. Certainly could remove it but felt like it was a potential gap that was worth filling.
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
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.
When
max_protocol_versionis not explicitly set, the default value is set to "3.0". This is reasonable and is inline with the same behavior as libpq[1]. Though, what libpq attempts to do that was not being done here is to reasonably upgrade or auto-raise the value ofmax_protocol_versionwhen it has not been explicitly set.Here, we're providing the same functionality. In libpq, this determination is based on the parsed config values. We do the same here, parsing the values in ParseConfig to validate and determine the appropriate default for max_protocol_version. The string fields on Config are then set accordingly, and re-parsed at connection time as before.
After parsing, when
max_protocol_versionhas not been explicitly set, ifmin_protocol_versionis greater than 3.0,max_protocol_versiondefaults tolatest; otherwise it defaults to 3.0 for compatibility with older servers/poolers that don't support NegotiateProtocolVersion.[1] postgres/postgres@285613c
Fixes: #2525