Re: Improve LWLock tranche name visibility across backends

On Mon, Jul 14, 2025 at 02:34:00PM -0500, Sami Imseih wrote:
>> Why do we need three different places for the lock names? Is there a
>> reason we can't put it all in shared memory?
>
> The real reason I felt it was better to keep three separate locations is that
> it allows for a clear separation between user-defined tranches registered
> during postmaster startup and those registered during a normal backend. The
> tranches registered during postmaster are inherited by the backend via
> fork() (or EXEC_BACKEND), and therefore, the dshash table will only be used
> by a normal backend.
>
> Since DSM is not available during postmaster, if we were to create a DSA
> segment in place, similar to what's done in StatsShmemInit(), we would also
> need to ensure that the initial shared memory is sized appropriately. This is
> because it would need to be large enough to accommodate all user-defined
> tranches registered during postmaster, without having to rely on new
> dsm segments.
> From my experimentation, this sizing is not as straightforward as simply
> calculating # of tranches * size of a tranche entry.
>
> I still think we should create the dsa during postmaster, as we do with
> StatsShmemInit, but it would be better if postmaster keeps its hands off this
> dshash and only normal backends can use them.

Ah, I missed the problem with postmaster. Could we have the first backend
that needs to access the table be responsible for creating it and
populating it with the built-in/requested-at-startup entries? Also, is
there any chance that postmaster might need to access the tranche names?

--
nathan