Horton

Re: Make query cancellation keys longer

Jelte Fennema-Nio <postgres@jeltef.nl>

View thread View on postgr.es
From: Jelte Fennema-Nio <postgres@jeltef.nl>
To: Peter Eisentraut <peter@eisentraut.org>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2024-03-03T06:59:15Z
Lists: pgsql-hackers 
On Fri, 1 Mar 2024 at 15:19, Peter Eisentraut <peter@eisentraut.org> wrote:
> > One complication with this was that because we no longer know how long
> > the key should be, 4-bytes or something longer, until the backend has
> > performed the protocol negotiation, we cannot generate the key in the
> > postmaster before forking the process anymore.
>
> Maybe this would be easier if it's a protocol version number change,
> since that is sent earlier than protocol extensions?

Protocol version and protocol extensions are both sent in the
StartupMessage, so the same complication applies. (But I do agree that
a protocol version bump is more appropriate for this type of change)

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