Re: Make query cancellation keys longer - Mailing list pgsql-hackers

From Jelte Fennema-Nio
Subject Re: Make query cancellation keys longer
Date
Msg-id CAGECzQTfc_O+HXqAo5_-xG4r3EFVsTefUeQzSvhEyyLDba-O9w@mail.gmail.com
Whole thread Raw
In response to Re: Make query cancellation keys longer  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Mon, 9 Sept 2024 at 17:58, Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Fri, Aug 16, 2024 at 11:29 AM Robert Haas <robertmhaas@gmail.com> wrote:
> > > I'll split this patch like that, to make it easier to compare and merge
> > > with Jelte's corresponding patches.
> >
> > That sounds great. IMHO, comparing and merging the patches is the next
> > step here and would be great to see.
>
> Heikki, do you have any update on this work?

My patchset in the other protocol thread needed a rebase. So I took
that as an opportunity to rebase this patchset on top of it, because
this seems to be the protocol change that we can most easily push over
the finish line.

1. I changed the last patch from Heikki to only contain the changes
for the cancel lengthening. The general protocol change related things
I merged with mine (I only kept some error handling and docs).
2. I also removed the length field in the new BackendKey definition,
eventhough I asked for that addition previously. I agree with Heikki
that it's actually easier to parse and create without, because you can
use the same code for both versions.
3. I made our timingsafe_bcmp implementation call into OpenSSL's CRYPTO_memcmp.

One open question on the last patch is: Document what the maximum size
of the cancel key is that the client can expect? I think Jacob might
have some ideas on that.

Attachment

pgsql-hackers by date:

Previous
From: Richard Guo
Date:
Subject: Re: Virtual generated columns
Next
From: Alexander Lakhin
Date:
Subject: Re: generic plans and "initial" pruning