> 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
v15-0001-Improve-LWLock-tranche-registration.patch
Description: Binary data
v15-0003-Remove-the-DSA-suffix-for-tranches-created-with-.patch
Description: Binary data
v15-0002-Tests-for-LWLock-tranche-registration-improvemen.patch
Description: Binary data
