On Mon, Jun 23, 2025 at 9:24 AM Jelte Fennema-Nio <postg...@jeltef.nl> wrote: > On Mon, 23 Jun 2025 at 18:02, Jacob Champion > <jacob.champ...@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
