| From: | Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com> |
| Subject: | Re: Make query cancellation keys longer |
| Date: | 2024-09-05 16:33:52 |
| Message-ID: | CAOYmi+kR0-jNmZWF5fQdo+81Qtgv=Qj-6kj9COXXGOpP63rwZw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Sep 5, 2024 at 9:21 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Wasn't this already addressed in v17, by
>
> Author: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
> 2024-03-12 [61461a300] libpq: Add encrypted and non-blocking query cancellation
>
> ? Perhaps we need to run around and make sure none of our standard
> clients use the old API anymore, but the libpq infrastructure is
> there already.
Right. From a quick grep, it looks like we have seven binaries using
the signal-based cancel handler.
(For programs that only send a cancel request right before they break
the connection, it's probably not worth a huge amount of effort to
change it right away, but for psql in particular I think the status
quo is a little weird.)
Thanks,
--Jacob
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jelte Fennema-Nio | 2024-09-05 16:36:10 | Re: Make query cancellation keys longer |
| Previous Message | Robert Haas | 2024-09-05 16:25:27 | Re: scalability bottlenecks with (many) partitions (and more) |