Re: [PATCH] Avoid pallocs in async.c's SignalBackends critical section - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [PATCH] Avoid pallocs in async.c's SignalBackends critical section
Date
Msg-id 954729.1764000372@sss.pgh.pa.us
Whole thread Raw
In response to Re: [PATCH] Avoid pallocs in async.c's SignalBackends critical section  (Heikki Linnakangas <hlinnaka@iki.fi>)
Responses Re: [PATCH] Avoid pallocs in async.c's SignalBackends critical section
List pgsql-hackers
Heikki Linnakangas <hlinnaka@iki.fi> writes:
> On 23/11/2025 16:45, Joel Jacobson wrote:
>> This patch addresses this comment in async.c's SignalBackends:
>> * XXX in principle these pallocs could fail, which would be bad.
>> * Maybe preallocate the arrays?  They're not that large, though.

> Ugh. I wonder if we should put an actual critical section around those
> post-commit cleanup actions? As you said, it's effectively a critical
> section already, except that we don't get the benefit of the
> AssertNotInCriticalSection assertions.
> Or even better, could we move things out of that effective critical
> section? It's painful to write code that cannot palloc.

I don't think Joel did anybody any favors by separating this patch
fragment from its larger context [1].  Given the infrequency of
complaints about failures in this area, I'm not sure that the
notational pain of an actual critical section is justified.
But I complained that the changes contemplated in [1] were raising
the probability of failure, and while working on tamping that back
down we decided to do something about this old gripe too.

There's a relevant comment in CommitTransaction():

     * This is all post-commit cleanup.  Note that if an error is raised here,
     * it's too late to abort the transaction.  This should be just
     * noncritical resource releasing.

Unfortunately, releasing locks, sending notifies, etc is not all
that "noncritical" if you want the DB to keep functioning well.
But there's a good deal of code in there and making it all obey
the critical-section rules looks painful.

            regards, tom lane

[1] https://www.postgresql.org/message-id/flat/6899c044-4a82-49be-8117-e6f669765f7e@app.fastmail.com



pgsql-hackers by date:

Previous
From: Jim Jones
Date:
Subject: Re: Add notification on BEGIN ATOMIC SQL functions using temp relations
Next
From: Tom Lane
Date:
Subject: Re: get rid of Pointer type, mostly