Re: [PATCH] Assertion in pg_get_shmem_pagesize() in single-user mode - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: [PATCH] Assertion in pg_get_shmem_pagesize() in single-user mode
Date
Msg-id 67463f89-f88a-4ec6-b83b-7adbfbfda899@iki.fi
Whole thread
In response to [PATCH] Assertion in pg_get_shmem_pagesize() in single-user mode  (Ayush Tiwari <ayushtiwari.slg01@gmail.com>)
List pgsql-hackers
On 21/09/2026 02:51, Ayush Tiwari wrote:
> While trying pg_buffercache in single-user mode, I noticed what looks
> like an overly restrictive assertion in pg_get_shmem_pagesize(). With
> pg_buffercache installed and the server stopped, I can reproduce this
> on an assertion-enabled build:
> 
>      $ postgres --single -D "$PGDATA" postgres
>      backend> SELECT pg_buffercache_os_pages(false) LIMIT 1;
>      TRAP: failed Assert("IsUnderPostmaster")
> 
> AFAICS, PostgresSingleUserMain() calls
> CreateSharedMemoryAndSemaphores() before processing queries, so
> huge_pages_status should already be initialized at this point.
> However, IsUnderPostmaster is false in a standalone backend.
> 
> Could we drop that assertion and retain the existing
> Assert(huge_pages_status != HUGE_PAGES_UNKNOWN)? That seems to check
> the relevant precondition without excluding single-user mode. This
> also doesn't appear specific to NUMA, since the query above requests
> only OS-page mappings.

Agreed.

> The attached patch removes the process-role assertion and adjusts the
> comment to refer to shared-memory creation. The query seems to work
> with this change in my local testing.
> 
> Does this look reasonable, or am I overlooking another reason for
> the IsUnderPostmaster check?

+1. Committed, thanks!

- Heikki




pgsql-hackers by date:

Previous
From: Nisha Moond
Date:
Subject: Re: Fix "unexpected logical decoding status change" error; from concurrent logical decoding activation
Next
From: Daniel Gustafsson
Date:
Subject: Re: [PATCH] Add ALTER SYSTEM RELOAD