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-09T08:53:20Z
Lists: pgsql-hackers
On 08/04/2025 22:41, Heikki Linnakangas wrote: > On 08/04/2025 20:06, Peter Eisentraut wrote: >> While I was looking at this, I suggest to make the first argument void >> *. This is consistent for passing binary data. > > Ok, sure. On second thoughts, -1 on that. 'void *' is appropriate for functions like libc's read() or pq_sendbytes(), where the buffer can point to anything. In other words, the caller is expected to have a pointer like 'foobar *', and it gets cast to 'void *' when you call the function. That's not the case with the cancellation key. The cancellation key is just an array of bytes, the caller is expected to pass an array of bytes, not a struct. The right precedent for that are e.g. SCRAM functions in scram-common.h, for example. They use "const uint8 *" for the hashes. I'll switch to "const uint *" everywhere that deals with cancel keys. There are a few more variables elsewhere in the backend and in libpq. > Looks good to me. I can commit these tomorrow, or feel free to do it > yourself too. I'm on this now. -- 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