Re: add function for creating/attaching hash table in DSM registry - Mailing list pgsql-hackers

From Nathan Bossart
Subject Re: add function for creating/attaching hash table in DSM registry
Date
Msg-id aEiTzmndOVPmA6Mm@nathan
Whole thread Raw
In response to Re: add function for creating/attaching hash table in DSM registry  (Sami Imseih <samimseih@gmail.com>)
List pgsql-hackers
On Tue, Jun 10, 2025 at 02:05:16PM -0500, Sami Imseih wrote:
> There is also that dynamic tranche named are stored in local backend
> look-up table, so if you have some backends that attached some dynamic
> hash table
> and others that did not, only the ones that registered would be able to
> resolve the tranche id to its name.
> 
> This is the case which I encountered yesterday, in which I tested 2
> backends competing for a LWLock on the dshash table, but a third backend
> that did not attach the hashtable reported the wait_event as "extension"
> rather than the extension-specified tranche name.
> 
> If that third backend attaches the hash table, then it's able to report
> the wait_event as the tranche name specified by the extension. So that
> could be confusing as 2 wait events could be reported for the same
> code path. right?

My initial reaction to this was "well yeah, that's how it's designed."  But
after some more research, I see that LWLockRegisterTranche() (commit
ea9df81) predates both the removal of dynamic_shared_memory_type=none
(commit bcbd940) and the introduction of DSAs (commit 13df76a).  lwlock.h
even still has this (arguably outdated) comment:

 * It may seem strange that each process using the tranche must register it
 * separately, but dynamic shared memory segments aren't guaranteed to be
 * mapped at the same address in all coordinating backends, so storing the
 * registration in the main shared memory segment wouldn't work for that case.

So, if we were adding named LWLocks today, I suspect we might do it
differently.  The first thing that comes to mind is that we could store a
shared LWLockTrancheNames table and stop requiring each backend to register
them individually.  For a concrete example, the autoprewarm shared memory
initialization code would become something like:

    static void
    apw_init_state(void *ptr)
    {
        AutoPrewarmSharedState *state = (AutoPrewarmSharedState *) ptr;

        LWLockInitialize(&state->lock, LWLockNewTrancheId("autoprewarm"));
        ...
    }

    static bool
    apw_init_shmem(void)
    {
        bool        found;

        apw_state = GetNamedDSMSegment("autoprewarm",
                                       sizeof(AutoPrewarmSharedState),
                                       apw_init_state,
                                       &found);
        return found;
    }

In short, LWLockNewTrancheId() would gain a new name argument, and
LWLockRegisterTranche() would disappear.  We would probably need to be
smart to avoid contention on the name table, but that feels avoidable to
me.

-- 
nathan



pgsql-hackers by date:

Previous
From: Sami Imseih
Date:
Subject: Re: add function for creating/attaching hash table in DSM registry
Next
From: Nathan Bossart
Date:
Subject: Re: Improve tab completion for COPY