On Mon, Apr 29, 2024 at 8:24 AM Heikki Linnakangas <hlinn...@iki.fi> wrote: > I was mostly worried about the refactoring of the > retry logic in libpq (and about the pre-existing logic too to be honest, > it was complicated before these changes already).
Some changes in the v17 negotiation fallback order caught my eye: 1. For sslmode=prefer, a modern v3 error during negotiation now results in a fallback to plaintext. For v16 this resulted in an immediate failure. (v2 errors retain the v16 behavior.) 2. For gssencmode=prefer, a legacy v2 error during negotiation now results in an immediate failure. In v16 it allowed fallback to SSL or plaintext depending on sslmode. Are both these changes intentional/desirable? Change #1 seems to partially undo the decision made in a49fbaaf: > Don't assume that "E" response to NEGOTIATE_SSL_CODE means pre-7.0 server. > > These days, such a response is far more likely to signify a server-side > problem, such as fork failure. [...] > > Hence, it seems best to just eliminate the assumption that backing off > to non-SSL/2.0 protocol is the way to recover from an "E" response, and > instead treat the server error the same as we would in non-SSL cases. Thanks, --Jacob
