Re: pgsql: Move named LWLock tranche requests to shared memory.

On Wed, Sep 17, 2025 at 11:35:56AM +0900, Michael Paquier wrote:
> Since this commit has been merged, batta has kept failing.  Here is
> the first failure:
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=batta&dt=2025-09-12%2002%3A05%3A01

Thanks for bringing this to my attention.

> And here is the backtrace:
> #0  0x000055fcdf6bc97a in NumLWLocksForNamedTranches () at lwlock.c:385
> 385 numLocks += NamedLWLockTrancheRequestArray[i].num_lwlocks;
> (gdb) bt
> #0  0x000055fcdf6bc97a in NumLWLocksForNamedTranches () at lwlock.c:385 
> #1  0x000055fcdf6bc9b3 in LWLockShmemSize () at lwlock.c:400 
> #2  0x000055fcdf65bda5 in CalculateShmemSize (num_semaphores=0x7ffcaf7a78e4) at ipci.c:130 
> #3  0x000055fcdf65c0b1 in CreateSharedMemoryAndSemaphores () at ipci.c:210 
> #4  0x000055fcdf42830c in PostmasterStateMachine () at postmaster.c:3223 
> #5  0x000055fcdf42703f in process_pm_child_exit () at postmaster.c:2558 
> #6  0x000055fcdf425729 in ServerLoop () at postmaster.c:1696 
> #7  0x000055fcdf424be1 in PostmasterMain (argc=4, argv=0x55fd0a8faa10) at postmaster.c:1403 
> #8  0x000055fcdef80a19 in main (argc=4, argv=0x55fd0a8faa10) at main.c:231
> (gdb) p i
> $3 = 0
> (gdb) p NamedLWLockTrancheRequestArray[0]
> Cannot access memory at address 0x7f15ee4ccc08

It looks like the postmaster is trying to access the request array after
re-initializing shared memory, which of course fails.  So, we need to keep
the request array in postmaster's local memory, too.  Attached is a quick
attempt at a fix.

-- 
nathan