Re: BackendKeyData is mandatory?

From: Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>
To: Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>
Cc: Tatsuo Ishii <ishii(at)postgresql(dot)org>, hlinnaka(at)iki(dot)fi, peter(at)eisentraut(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: BackendKeyData is mandatory?
Date: 2025-06-23 16:23:53
Message-ID: CAGECzQTRDjSHZ-RLvTRGcsY_EzGX9nVxEgYGZpz1tw9x45dGPQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, 23 Jun 2025 at 18:02, Jacob Champion
<jacob(dot)champion(at)enterprisedb(dot)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.

To be clear, I'm not saying we should start throwing errors for things
in libpq that weren't errors before. But more as: I don't expect many
client authors to have considered the scenario of no BackendKeyData.
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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2025-06-23 16:26:22 Re: pgsql: Introduce pg_shmem_allocations_numa view
Previous Message jian he 2025-06-23 16:11:27 Re: pg18: Virtual generated columns are not (yet) safe when superuser selects from them