From: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
---|---|
To: | Peter Eisentraut <peter(at)eisentraut(dot)org>, pgsql-committers(at)lists(dot)postgresql(dot)org |
Subject: | Re: pgsql: Make cancel request keys longer |
Date: | 2025-04-08 19:41:31 |
Message-ID: | 09323e6a-4743-4be2-9d7f-74b86e4dac64@iki.fi |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers 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)
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Gustafsson | 2025-04-08 21:22:04 | pgsql: Rename argument in pg_get_process_memory_contexts(). |
Previous Message | Wolfgang Walther | 2025-04-08 17:54:55 | Re: pgsql: Add support for basic NUMA awareness |
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2025-04-08 19:51:54 | Re: Move tests of contrib/spi/ out of the core regression tests |
Previous Message | Hannu Krosing | 2025-04-08 19:41:06 | Re: Horribly slow pg_upgrade performance with many Large Objects |