> > Another approach is to just change GetNamedLWLockTranche to use
> > NamedLWLockTrancheArray since that is already copied in EXEC_BACKEND, and
> > allow GetNamedLWLockTranche to continue to be used outside of startup. In
> > this case, we will need to add num_lwlocks field to
> > NamedLWLockTrancheArray. This might be better to backpatch, since we will
> > not be changing user facing behavior.
>
> That seems like a reasonable thing to try. It looks like
> NamedLWLockTrancheRequests is copied, too. Could we used that instead of
> adding a new variable?
We would not need a new variable. Currently it's assumed that
NamedLWLockTrancheRequests will be the size of both
NamedLWLockTrancheRequests and NamedLWLockTrancheArray.
```
/*
* NamedLWLockTrancheRequests is both the valid length of the request array,
* and the length of the shared-memory NamedLWLockTrancheArray later on.
* This variable and NamedLWLockTrancheArray are non-static so that
* postmaster.c can copy them to child processes in EXEC_BACKEND builds.
*/
int NamedLWLockTrancheRequests = 0;
```
> My guess is that this has been broken since this code was introduced in
> commit c1772ad from 2016/v9.6, and AFAIK you are the first to report it, so
> I don't feel a tremendous amount of urgency to fix it on the back-branches.
Yeah, I was doing something for testing that is not likely to be done in
the real-world. Also, considering this is an EXEC_BACKEND case only,
it makes it even less likely.
--
Sami
