| 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
| 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 |