Re: Direct SSL connection and ALPN loose ends

On Mon, Apr 29, 2024 at 8:24 AM Heikki Linnakangas <hlinnaka@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