Re: Clean up NamedLWLockTranche stuff

On 28/03/2026 00:05, Nathan Bossart wrote:
> On Fri, Mar 27, 2026 at 04:50:12PM -0500, Nathan Bossart wrote:
>> On Fri, Mar 27, 2026 at 05:22:33PM -0400, Andres Freund wrote:
>>> TRAP: failed Assert("MemoryContextIsValid(context)"), File: "mcxt.c", Line: 1270, PID: 230491
>>> [...](ExceptionalCondition+0x54)[0xaaaae186c204]
>>> [...](MemoryContextAllocExtended+0x0)[0xaaaae18a2a24]
>>> [...](RequestNamedLWLockTranche+0x6c)[0xaaaae16e7310]
>>> [...](process_shmem_requests+0x28)[0xaaaae1881628]
>>> [...](PostgresSingleUserMain+0xc4)[0xaaaae1701a34]
>>> [...](main+0x6ac)[0xaaaae12a2adc]
>>> /lib/aarch64-linux-gnu/libc.so.6(__libc_start_main+0xe8)[0xffff99713dd8]
>>> [...](+0xf2b98)[0xaaaae12a2b98]
>>> Aborted
>>> pg_rewind: error: postgres single-user mode in target cluster failed
>>
>> Hm. AFAICT PostmasterContext isn't created in single-user mode, and the
>> commit in question has RequestNamedLWLockTranche() allocate requests there.
>> I guess the idea is to allow backends to free that memory after forking
>> from postmaster, but we don't do that for the NamedLWLockTrancheRequests
>> list. Maybe we should surround the last part of that function with
>> MemoryContextSwitchTo(...) to either TopMemoryContext or PostmasterContext
>> depending on whether we're in single-user mode.
>
> Concretely, like the attached.

LGTM, thanks! Will you commit or want me to pick it up?

- Heikki