Re: BUG #19416: Backend SIGSEGV in ExecShutdownHashJoin/ExecHashTableDetach/dsa_free

On Thu, Feb 26, 2026 at 11:28 AM PG Bug reporting form
<noreply(at)postgresql(dot)org> wrote:
> #0 0x0000564830c3c9d1 in dsa_free (area=0x5648621a9280, dp=<optimized out>)
> at ./build/../src/backend/utils/mmgr/dsa.c:845
> 845 ./build/../src/backend/utils/mmgr/dsa.c: No such file or directory.
> (gdb) bt full
> #0 0x0000564830c3c9d1 in dsa_free (area=0x5648621a9280, dp=<optimized out>)
> at ./build/../src/backend/utils/mmgr/dsa.c:845
> segment_map = 0x5648621a92b8
> pageno = 0
> span_pointer = 0
> span = <optimized out>
> superblock = <optimized out>
> object = <optimized out>
> size = <optimized out>
> size_class = <optimized out>
> #1 0x0000564830917ae1 in ExecHashTableDetach (hashtable=0x564862147fa0) at
> ./build/../src/backend/executor/nodeHash.c:3439
> i = <optimized out>
> pstate = 0x7ef9970b5040

Hmm, it's not supposed to be possible for two backends to reach the
dsa_free() at nodeHash.c:3439. But it does smell a bit like that
that's what happened... hmmm. We were in _RUN phase, and then this
barrier should only let one process through to _FREE. I'd be
interested in the contents of pstate->build_barrier in frame 1 if you
get another core file with the same stack in it. Can you share the
outline of the query plan? Does it happen to have a full/right PHJ
in it?

/* If we're last to detach, clean up shared memory. */
if (BarrierArriveAndDetach(&pstate->build_barrier))
{
/*
* Late joining processes will see this state and give up
* immediately.
*/
Assert(BarrierPhase(&pstate->build_barrier) == PHJ_BUILD_FREE);

if (DsaPointerIsValid(pstate->batches))
{
dsa_free(hashtable->area, pstate->batches);
pstate->batches = InvalidDsaPointer;
}
}