Re: BUG #19416: Backend SIGSEGV in ExecShutdownHashJoin/ExecHashTableDetach/dsa_free - Mailing list pgsql-bugs

On Thu, Feb 26, 2026 at 11:28 AM PG Bug reporting form
<noreply@postgresql.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;
            }
        }