Horton

Re: Make query cancellation keys longer

Thomas Munro <thomas.munro@gmail.com>

View thread View on postgr.es
From: Thomas Munro <thomas.munro@gmail.com>
To: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: Jelte Fennema-Nio <postgres@jeltef.nl>, pgsql-hackers <pgsql-hackers@postgresql.org>, Robert Haas <robertmhaas@gmail.com>
Date: 2024-08-12T11:45:44Z
Lists: pgsql-hackers 
+     * See if we have a matching backend. Reading the pss_pid and
+     * pss_cancel_key fields is racy, a backend might die and remove itself
+     * from the array at any time.  The probability of the cancellation key
+     * matching wrong process is miniscule, however, so we can live with that.
+     * PIDs are reused too, so sending the signal based on PID is inherently
+     * racy anyway, although OS's avoid reusing PIDs too soon.

Just BTW, we know that Windows sometimes recycles PIDs very soon,
sometimes even immediately, to the surprise of us Unix hackers.  It can
make for some very confusing build farm animal logs.  My patch will
propose to change that particular thing to proc numbers anyway so I'm
not asking for a change here, I just didn't want that assumption to go
un-footnoted.  I suppose that's actually (another) good reason to want
to widen the cancellation key, so that we don't have to worry about
proc number allocation order being less protective than traditional
Unix PID allocation...

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