Re: Clean up NamedLWLockTranche stuff - Mailing list pgsql-hackers

From Nathan Bossart
Subject Re: Clean up NamedLWLockTranche stuff
Date
Msg-id acb7lL5zrsieS9k3@nathan
Whole thread Raw
In response to Re: Clean up NamedLWLockTranche stuff  (Andres Freund <andres@anarazel.de>)
Responses Re: Clean up NamedLWLockTranche stuff
List pgsql-hackers
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.

-- 
nathan



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: refactor func-matching.sgml, make regexp* function more readable
Next
From: Peter Geoghegan
Date:
Subject: Re: index prefetching