Re: add assertion for palloc in signal handlers

> On Feb 18, 2026, at 06:24, Nathan Bossart <nathandbossart(at)gmail(dot)com> wrote:
>
> (new thread)
>
> On Tue, Feb 17, 2026 at 03:30:57PM -0600, Nathan Bossart wrote:
>> On Tue, Feb 17, 2026 at 11:18:00PM +0200, Heikki Linnakangas wrote:
>>> On 14/02/2026 23:56, Andres Freund wrote:
>>>> We really need some instrumentation that fails if we do allocations in signal
>>>> handlers etc.
>>>
>>> Yeah, that would be nice..
>>
>> In theory we could pretty easily add assertions for that, given the
>> wrapper_handler business added a couple of years ago. I'll put together a
>> patch...
>
> As promised... Fortunately, check-world didn't uncover any existing
> issues. I was able to manually verify the assertion by switching a
> background worker to use bgworker_die() and sending it SIGTERM. Probably
> could use some additional commentary, which I'll add if the idea seems
> reasonable to you.
>
> --
> nathan
> <v1-0001-Add-an-assertion-that-you-don-t-palloc-in-a-signa.patch>

···
+#ifndef FRONTEND
+volatile sig_atomic_t InSignalHandler = false;
+#endif
+
/*
* Except when called with SIG_IGN or SIG_DFL, pqsignal() sets up this function
* as the handler for all signals. This wrapper handler function checks that
@@ -99,6 +103,8 @@ wrapper_handler(SIGNAL_ARGS)
Assert(MyProcPid);
Assert(MyProcPid != PostmasterPid || !IsUnderPostmaster);

+ InSignalHandler = true;
+
if (unlikely(MyProcPid != (int) getpid()))
{
pqsignal(postgres_signal_arg, SIG_DFL);
···

When entering “if (unlikely(MyProcPid != (int) getpid()))”, it returns without setting InSignalHandler to false, is that intentional?

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/