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

From Andres Freund
Subject Re: Improve LWLock tranche name visibility across backends
Date
Msg-id 34drxi6kshtzu5aerftjflrm6wfxxw54emyvy4gqemdpxxuhvm@gymw6its72o7
Whole thread Raw
In response to Re: Improve LWLock tranche name visibility across backends  (Nathan Bossart <nathandbossart@gmail.com>)
Responses Re: Improve LWLock tranche name visibility across backends
List pgsql-hackers
Hi,

On 2025-08-19 12:29:14 -0500, Nathan Bossart wrote:
> On Tue, Aug 19, 2025 at 08:09:53AM +0000, Bertrand Drouvot wrote:
> > On Mon, Aug 18, 2025 at 05:53:44PM -0500, Sami Imseih wrote:
> >> > (or some other shmem-based
> >> > data structure we have yet to introduce, like a dslist/dsarray).
> >> 
> >> This will be an interesting API to invest time in, if there could be more
> >> use-cases.
> > 
> > I did a quick check and I did not find current use cases: possible candidates
> > could be in ExecParallelHashTableAlloc(), PTIterationArray, PTEntryArray for
> > examples but I think they all know the final size upfront so there is no real
> > need for dsarray for those).
> > 
> >> I think it's a separate discussion at this point.
> > 
> > OTOH, that would be a valid use case to introduce this new API but I'm not sure
> > it's worth it given that the dshash looks good enough for our case (even if not
> > ideal though).
> 
> IMHO it'd be okay to proceed with dshash for now.  It would be pretty easy
> to switch to something like a "dslist" in the future.

Possibly stupid question - is it really worth having a dynamic structure here?
The number of tranches is strictly bound, it seems like it'd be simpler to
have an array of tranch nmes in shared memory.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Álvaro Herrera
Date:
Subject: Re: New commitfest app release on August 19th
Next
From: Tom Lane
Date:
Subject: Re: VM corruption on standby