Re: Improve LWLock tranche name visibility across backends

> The check has to be done before the strlen() call, if not it segfault:

I don't know what I was thinking there :( silly mistake.
It was also missed in RequestNamedLWLockTranche.

> Most of the places where NAMEDATALEN is mentioned in sgml files also mention
> it's 64 bytes. Should we do the same here?

I don't have an issue with that, although I did not like how the
various docs are not
consistent. Some claim 64 characters, others claim 63 bytes. They are
not the same
since multibyte characters are allowed. For example [0] is definitely wrong,
and it should say "bytes".
I think it would be nice if all references to NAMEDATALEN point to a single doc
(a follow-up topic, perhaps)

> "Any unused entries in the array will contain NULL": this is not true anymore.
> It now contains empty strings:

Yes. Fixed the comment.

Also, it has not yet been discussed that the max number of named
tranches should be.
Thus far I have been using a likely extremely high value of 1024. In
v15, I set it to 128
as that was a possibly more realistic number and one suggested earlier [1].

There maybe some odd cases out there in which this value may not be enough;
many extensions that init lwlocks or maybe some extension out there that uses
partitioned locks and assign a unique tranche for every lock. I have
not seen anything
like this. Maybe it's not be something to worry about and we can say
128 is reasonable sufficiently
large. I would hate to reserve too much shared memory for this unnecessarily.

Thoughts?

[0] https://www.postgresql.org/docs/18/runtime-config-logging.html#GUC-APPLICATION-NAME
[1] https://www.postgresql.org/message-id/5to6tftuml6nkas4jaaljfzecasvslxq3mumeslh74wsol4mzw%40rgxpxxlqqwtf

--
Sami