Re: BackendKeyData is mandatory?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>
Cc: Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>, 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 19:48:10
Message-ID: 4089897.1750708090@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jelte Fennema-Nio <postgres(at)jeltef(dot)nl> writes:
> On Mon, 23 Jun 2025 at 18:42, Jacob Champion
> <jacob(dot)champion(at)enterprisedb(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Christoph Berg 2025-06-23 19:57:56 Re: pgsql: Introduce pg_shmem_allocations_numa view
Previous Message Melanie Plageman 2025-06-23 19:21:19 Simplify VM counters in vacuum code