Horton

Re: Make query cancellation keys longer

Tomas Vondra <tomas.vondra@enterprisedb.com>

View thread View on postgr.es
From: Tomas Vondra <tomas.vondra@enterprisedb.com>
To: Heikki Linnakangas <hlinnaka@iki.fi>, Jelte Fennema-Nio <postgres@jeltef.nl>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>, Thomas Munro <thomas.munro@gmail.com>, Robert Haas <robertmhaas@gmail.com>
Date: 2024-07-04T12:43:20Z
Lists: pgsql-hackers 
Hi,

I don't have any immediate feedback regarding this patch, but I'm
wondering about one thing related to cancellations - we talk cancelling
a query, but we really target a PID (or a particular backend, no matter
how we identify it).

I occasionally want to only cancel a particular query, but I don't think
that's really possible - the query may complete meanwhile, and the
backend may even get used for a different user connection (e.g. with a
connection pool)? Or am I missing something important?

Anyway, I wonder if making the cancellation key longer (or variable
length) might be useful for this too - it would allow including some
sort of optional "query ID" in the request, not just the PID. (Maybe
st_xact_start_timestamp would work?)

Obviously, that's not up to this patch, but it's somewhat related.



regards

-- 
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

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