On Mon, Jun 23, 2025 at 9:24 AM Jelte Fennema-Nio <postgres@jeltef.nl> wrote:
> On Mon, 23 Jun 2025 at 18:02, Jacob Champion
> <jacob.champion@enterprisedb.com> wrote:
> > If anyone today is relying on "backend-key-less" connection, this is
> > potentially a breaking change. For example, psycopg2 now complains:
> >
> > psycopg2.OperationalError: can't get cancellation key
>
> It's not super clear what you're referring to with "this" in your
> first sentence.
The change in behavior in 18, if the server doesn't send a cancellation key.
> To be clear, I'm not saying we should start throwing errors for things
> in libpq that weren't errors before.
But that is _exactly_ what we've started doing now, in 18. We return
NULL instead of an "empty" cancellation object, and at least one
existing client fails because of it. Whether that's a problem in
practice is, I guess, part of the open question of this thread.
> But more as: I don't expect many
> client authors to have considered the scenario of no BackendKeyData.
I agree.
> Because either an author believes the BackendKeyData is optional, in
> which case they shouldn't send a CancelRequest for those connections.
> Or they think it is required, in which case throwing an error seems
> like the sensible thing to do. And the implementations in PgBouncer
> and PG17 is neither, i.e. it won't throw an error, but instead of
> doing nothing it will do something clearly useless.
From reading this thread, I'm not convinced that's "clear". I wouldn't
have chosen the existing behavior, for sure, but any existing servers
that don't send a key must be doing _something_ with that cancel
request, right? Even if it's just ignored?
Do we know which implementations aren't sending keys?
--Jacob
