Re: pgsql: Make cancel request keys longer
Heikki Linnakangas <hlinnaka@iki.fi>
From: Heikki Linnakangas <hlinnaka@iki.fi>
To: Peter Eisentraut <peter@eisentraut.org>,
pgsql-committers@lists.postgresql.org
Date: 2025-04-08T19:41:31Z
Lists: pgsql-hackers
On 08/04/2025 20:06, Peter Eisentraut wrote: > On 02.04.25 15:43, Heikki Linnakangas wrote: >> Make cancel request keys longer > > This patch changed the signature of ProcSignal() > > -ProcSignalInit(bool cancel_key_valid, int32 cancel_key) > +ProcSignalInit(char *cancel_key, int cancel_key_len) > > but did not update the caller in auxprocess.c: > > ProcSignalInit(false, 0); > > This gives a warning with clang. Good catch. I wonder why the cirrus CI didn't complain, it has a step to check for warnings with clang. > While I was looking at this, I suggest to make the first argument void > *. This is consistent for passing binary data. Ok, sure. > Also, I wonder why MyCancelKeyLength is of type uint8 rather than > something more mundane like int. There doesn't seem to be any API > reason for this type. Agreed. The cancel key length is documented to be at most 256 bytes, but that's more of a coincidence, nothing depends on that variable being uint8. > See attached patch for possible changes. Looks good to me. I can commit these tomorrow, or feel free to do it yourself too. Thank you! -- Heikki Linnakangas Neon (https://neon.tech)
Commits
-
Use 'void *' for arbitrary buffers, 'uint8 *' for byte arrays
- b28c59a6cd08 18.0 landed
-
Use more mundane 'int' type for cancel key lengths in libpq
- 965213d9c56a 18.0 landed
-
Fix a few oversights in the longer cancel keys patch
- 0f1433f05356 18.0 landed
-
Make cancel request keys longer
- a460251f0a1a 18.0 cited