Re: pgsql: Make cancel request keys longer

From: Peter Eisentraut <peter(at)eisentraut(dot)org>
To: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, pgsql-committers(at)lists(dot)postgresql(dot)org
Subject: Re: pgsql: Make cancel request keys longer
Date: 2025-04-09 09:39:49
Message-ID: 2afbd9c6-51b7-450f-9ae1-61e552368963@eisentraut.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

On 09.04.25 10:53, Heikki Linnakangas wrote:
> 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.

I was having the same second thoughts overnight. I agree with your
conclusion.

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Heikki Linnakangas 2025-04-09 10:12:44 pgsql: Fix a few oversights in the longer cancel keys patch
Previous Message Heikki Linnakangas 2025-04-09 08:53:20 Re: pgsql: Make cancel request keys longer

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2025-04-09 09:45:08 Re: tab complete for COPY populated materialized view TO
Previous Message Amit Kapila 2025-04-09 09:29:22 Re: BUG #18815: Logical replication worker Segmentation fault