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