Re: Call CalculateShmemSize() only once

From: Nathan Bossart <nathandbossart(at)gmail(dot)com>
To: Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Heikki Linnakangas <heikki(dot)linnakangas(at)databricks(dot)com>
Subject: Re: Call CalculateShmemSize() only once
Date: 2026-10-30 17:55:39
Message-ID: auTZu_r4KzTWPQSS@nathan
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Oct 30, 2026 at 12:17:33PM +0100, Ashutosh Bapat wrote:
> During normal startup, we call CalculateShmemSize() twice: once to
> initialize the shared-memory-related GUCs and again to create the
> shared memory segment. We can avoid the second calculation by calling
> CalculateShmemSize() after ShmemCallRequestCallbacks() and passing the
> result to InitializeShmemGUCs() and CreateSharedMemoryAndSemaphores().
> The attached patch does this, ensuring that GUC reporting and shared
> memory creation use the same calculated size.

+1. I think it's my fault it's called twice. I don't recall why I didn't
bother trying to fix it, but I do think it's worth fixing.

> As a follow-up, would it make sense to introduce an SRS_SIZED state
> between SRS_REQUESTING and SRS_INITIALIZING? We could enter it when
> ShmemGetRequestedSize() finishes and adjust the state checks
> accordingly. This would prevent new requests from being registered
> after the required shared memory size has been calculated.
> EXEC_BACKEND child attachment and late allocation would retain their
> existing paths without entering this state. I can update the patch if
> this seems worthwhile.

Seems worth exploring.

> - CreateSharedMemoryAndSemaphores();
> + shmem_size = CalculateShmemSize();
> + CreateSharedMemoryAndSemaphores(shmem_size);

nitpick: When the variable is only used in one place, is there any reason
not to just do CreateSharedMemoryAndSemaphores(CalculateShmemSize())?

> /*
> * CalculateShmemSize
> * Calculates the amount of shared memory needed.
> + *
> + * Expected to be called only once after collecting all shared memory requests
> + * but before allocating the shared memory segment at the startup or server
> + * restart.
> */

Should we ERROR if it is called more than once? That might need some
special handling for the restart_after_crash case.

> -CreateSharedMemoryAndSemaphores(void)
> +CreateSharedMemoryAndSemaphores(Size size)

Should we verify the size looks reasonable? A "!= 0" check might be
worthwhile, at least.

> - * ShmemGetRequestedSize() --- estimate the total size of all registered shared
> - * memory structures.
> + * ShmemGetRequestedSize() --- estimate the total size of all registered shared
> + * memory structures.

nitpick: Unnecessary changes.

> - * This is called at postmaster startup, before the shared memory segment has
> - * been created.
> + * This is called at postmaster startup or server restart, before the shared
> + * memory segment has been created.

nitpick: This also seems unnecessary, or at least unrelated to the patch at
hand.

--
nathan

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Ayoub Kazar 2026-10-30 17:56:51 Re: Hash a ScalarArrayOpExpr whose array is fixed for one execution
Previous Message Greg Burd 2026-10-30 17:46:02 Re: Quickselect instead of a heap for ORDER BY ... LIMIT N large bounded sorts