Re: add assertion for palloc in signal handlers

From: Andres Freund <andres(at)anarazel(dot)de>
To: Nathan Bossart <nathandbossart(at)gmail(dot)com>
Cc: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: add assertion for palloc in signal handlers
Date: 2026-02-17 23:11:10
Message-ID: cbb4qkxobv6dqk3kgpd3caxehawxahmx4v2i2nz6vwjtcoujcy@rorcycaafmau
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2026-02-17 23:12:38 Re: Proposal: ANALYZE (MODIFIED_STATS) using autoanalyze thresholds
Previous Message Michael Paquier 2026-02-17 22:51:06 Re: One-off with syscache ID in get_catalog_object_by_oid_extended()