Re: Clean up NamedLWLockTranche stuff

Thanks!

On 26/03/2026 18:34, Sami Imseih wrote:
>> I propose the attached refactorings to make this less confusing. See
>> commit messages for details.
>
> I only took a look at 0001 so far, and I do agree with this statement
> in the commit message:
>
> "The "user defined" term was already used in LWTRANCHE_FIRST_USER_DEFINED,
> so let's standardize on that to mean tranches allocated with either
> RequestNamedLWLockTranche() or LWLockNewTrancheId()."
>
> I do wonder if 0001 is going far enough though.
>
> Instead of just standardizing that "user defined" could mean tranches allocated
> with RequestNamedLWLockTranche() or LWLockNewTrancheId(), how about we also
> rename these APIs to reflect that as well? This way we remove all concept of
> "named tranche" which is what it sounds like to me you are proposing.
>
> rename RequestNamedLWLockTranche() to RequestUserDefinedLWLockTranche()
> and LWLockNewTrancheId() to RegisterUserDefinedLWLockTranche()

I'd rather not change RequestNamedLWLockTranche(), because I think
LWLockNewTrancheId() is better and should be used in new code. I
consider RequestNamedLWLockTranche() to be a legacy function, for
backwards compatibility.

> RequestNamedLWLockTranche() requests the lwlock at shmem_request time,
> which is later registered via LWLockNewTrancheId() when lwlocks are
> initialized by the postmaster.
>
> Also, the name LWLockNewTrancheId() is selling what this function does
> too short.
> It does return a new tranche ID, but it also takes in a user-defined tranche
> name and copies ("registers") that name into LWLockTrancheNames.
>
> v19 is already changing the signature of LWLockNewTrancheId(), so maybe
> improving the names of these APIs makes sense to do.

Oh, I didn't realize we changed the LWLockNewTrancheId() signature!
Yeah, if we're changing it anyway, we might as well rename it. I'm not
sure if I like RegisterUserDefinedLWLockTranche() better, but let's
think it through.

- Heikki