From: Tom Lane <tgl@sss.pgh.pa.us>
To: Nathan Bossart <nathandbossart@gmail.com>
cc: Andres Freund <andres@anarazel.de>,
        Bertrand Drouvot <bertranddrouvot.pg@gmail.com>,
        Sami Imseih <samimseih@gmail.com>,
        Rahila Syed <rahilasyed90@gmail.com>,
        pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: Improve LWLock tranche name visibility across backends
In-reply-to: <aKTGF9Fv1ioXa9P5@nathan>
References: <aKL1w6tczBqsqLiJ@ip-10-97-1-34.eu-west-3.compute.internal>
 <CAA5RZ0uuWWL5z80KEs95Evy9CrQqnR6vY91BmFor5YmEf06j=w@mail.gmail.com>
 <CAA5RZ0vPcUb68h16ueg=A1R4ps=qU74jvG8N2xaX97DAK-E7_A@mail.gmail.com>
 <aKOeMUjcv9Gozyyg@nathan>
 <CAA5RZ0viNsKqjSuJ8fo74SJrf0uMi=igOn5WrtNYmVqYVh5h-w@mail.gmail.com>
 <aKQxUS6rtMzCkEia@ip-10-97-1-34.eu-west-3.compute.internal>
 <aKS0auEl4UUlt7XO@nathan>
 <34drxi6kshtzu5aerftjflrm6wfxxw54emyvy4gqemdpxxuhvm@gymw6its72o7>
 <aKTDB5mvSowmC0Lf@nathan>
 <5to6tftuml6nkas4jaaljfzecasvslxq3mumeslh74wsol4mzw@rgxpxxlqqwtf>
 <aKTGF9Fv1ioXa9P5@nathan>
Comments: In-reply-to Nathan Bossart <nathandbossart@gmail.com>
	message dated "Tue, 19 Aug 2025 13:44:39 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <876522.1755635201.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Tue, 19 Aug 2025 16:26:41 -0400
Message-ID: <876523.1755635201@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/876523.1755635201%40sss.pgh.pa.us>
Precedence: bulk

Nathan Bossart <nathandbossart@gmail.com> writes:
> On Tue, Aug 19, 2025 at 02:37:19PM -0400, Andres Freund wrote:
>> Sure, but we don't need to support a large number of tranches. Just mak=
e it,
>> idk, 128 entries long. Adding a dynamically allocated dsm to every serv=
er
>> seems like a waste - ever shared mapping makes fork / exit slower...

> The other issue is that there's presently no limit on the length of a
> tranche name registered via LWLockRegisterTranche().  Life would become
> much simpler if we're willing to put a limit on both that and the number=
 of
> tranches, but thus far we've been trying to avoid it.

I can hardly imagine a reason why it wouldn't be okay to limit the
lengths of tranche names.  But especially so if an unlimited length
causes practical problems.

			regards, tom lane