Re: add assertion for palloc in signal handlers - Mailing list pgsql-hackers

From Andres Freund
Subject Re: add assertion for palloc in signal handlers
Date
Msg-id cbb4qkxobv6dqk3kgpd3caxehawxahmx4v2i2nz6vwjtcoujcy@rorcycaafmau
Whole thread
In response to add assertion for palloc in signal handlers  (Nathan Bossart <nathandbossart@gmail.com>)
Responses Re: add assertion for palloc in signal handlers
List pgsql-hackers
Hi,

On 2026-02-17 16:24:58 -0600, Nathan Bossart wrote:
> 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.

Seems reasonable to me.  I guess we could put the various asserts into a
helper function, but it's ok as-is I think.

I think the spinlock functions should also assert this.

I'd advocate for adding an InSpinlock or such at the same time, but admittedly
there's not really anything forcing that to happen together.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: One-off with syscache ID in get_catalog_object_by_oid_extended()
Next
From: David Rowley
Date:
Subject: Re: Proposal: ANALYZE (MODIFIED_STATS) using autoanalyze thresholds