Re: Improve LWLock tranche name visibility across backends - Mailing list pgsql-hackers

From Sami Imseih
Subject Re: Improve LWLock tranche name visibility across backends
Date
Msg-id CAA5RZ0s4ip08Lsk=aYuXGCkBr78jhH=gOau939mhAp-rGuNC3Q@mail.gmail.com
Whole thread Raw
In response to Re: Improve LWLock tranche name visibility across backends  (Bertrand Drouvot <bertranddrouvot.pg@gmail.com>)
Responses Re: Improve LWLock tranche name visibility across backends
List pgsql-hackers
> 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

Attachment

pgsql-hackers by date:

Previous
From: Yugo Nagata
Date:
Subject: Re: Inconsistent update in the MERGE command
Next
From: Fabrice Chapuis
Date:
Subject: Re: Issue with logical replication slot during switchover