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
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 |