Re: Call CalculateShmemSize() only once

Hi Ashutosh,

On Fri, Oct 30, 2026 at 4:48 PM Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>
wrote:

> Hi all,
>
> 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, the patch LGTM except what Nathan already pointed out :)

> I considered combining these four calls into a single function.
> However, when postgres -C reports a runtime-computed GUC, it exits
> after GUC initialization without creating shared memory. Keeping
> sizing and GUC initialization separate from shared memory creation
> preserves that distinction.
>

I also wanted the same but somehow the API is ending up ugly as we need to
bring some stuff which doesn't "naturally" belong into this 1 API.

>
> We could also invoke ShmemCallRequestCallbacks() from
> CalculateShmemSize() to keep request collection and sizing together.
> That alone would not prevent additional requests after sizing, though.
>
> 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.
>
+1, i think this helps.

> I’m proposing this change for master. It may also be worth considering
> for PG 19 to reduce conflicts when backpatching future changes to this
> code, rather than as a bug fix in itself.
>
+1

--
Thanks :)
Srinath Reddy Sadipiralla
EDB: https://www.enterprisedb.com/