Horton

Re: Make query cancellation keys longer

Jacob Champion <jacob.champion@enterprisedb.com>

View thread View on postgr.es
From: Jacob Champion <jacob.champion@enterprisedb.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>, Jelte Fennema-Nio <postgres@jeltef.nl>, pgsql-hackers <pgsql-hackers@postgresql.org>, Thomas Munro <thomas.munro@gmail.com>, Robert Haas <robertmhaas@gmail.com>
Date: 2024-09-05T16:33:52Z
Lists: pgsql-hackers 
On Thu, Sep 5, 2024 at 9:21 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Wasn't this already addressed in v17, by
>
> Author: Alvaro Herrera <alvherre@alvh.no-ip.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

Commits

  1. Add timingsafe_bcmp(), for constant-time memory comparison

  2. Add missing declarations to pg_config.h.in

  3. docs: Add a new section and a table listing protocol versions

  4. Make cancel request keys longer

  5. libpq: Add min/max_protocol_version connection options

  6. libpq: Handle NegotiateProtocolVersion message differently

  7. docs: Update phrase on message lengths in the protocol

  8. libpq: Trace all NegotiateProtocolVersion fields

  9. libpq: Add PQfullProtocolVersion to exports.txt

  10. Move cancel key generation to after forking the backend