Horton

Re: BackendKeyData is mandatory?

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Jelte Fennema-Nio <postgres@jeltef.nl>
Cc: Jacob Champion <jacob.champion@enterprisedb.com>, Tatsuo Ishii <ishii@postgresql.org>, hlinnaka@iki.fi, peter@eisentraut.org, pgsql-hackers@postgresql.org
Date: 2025-06-23T19:48:10Z
Lists: pgsql-hackers 
Jelte Fennema-Nio <postgres@jeltef.nl> writes:
> On Mon, 23 Jun 2025 at 18:42, Jacob Champion
> <jacob.champion@enterprisedb.com> wrote:
>> 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?

> I mean if the only thing a server can do is ignore it, ISTM that it's
> clearly useless to send it anyway. Sending nothing seems a much better
> choice in that case.

It could be that the server has some independent way of knowing which
session to cancel.  (As a reductio-ad-absurdum case, maybe it only
supports one session.)

>> Do we know which implementations aren't sending keys?

> Nope, that's totally unclear. It would be very nice knowing which
> database this is, and if it's at all a production system.

Yeah, I'm very hesitant to spend any effort here without having
a more concrete use-case.

			regards, tom lane

Commits

  1. Revert unnecessary check for NULL

  2. libpq: Be strict about cancel key lengths

  3. libpq: Handle OOM by disconnecting instead of hanging or skipping msgs

  4. libpq: Complain about missing BackendKeyData later with PGgetCancel()