| From: | Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> |
|---|---|
| To: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Heikki Linnakangas <heikki(dot)linnakangas(at)databricks(dot)com> |
| Subject: | Call CalculateShmemSize() only once |
| Date: | 2026-10-30 11:17:33 |
| Message-ID: | CAExHW5ttQauXiYCM4OKL8xKHZrndTN2jMN4WQjm1PkPNuqX_bg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
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.
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.
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.
--
Best Wishes,
Ashutosh Bapat
| Attachment | Content-Type | Size |
|---|---|---|
| v20261030-0001-Call-CalculateShmemSize-only-once-when-cre.patch | text/x-patch | 9.0 KB |
| From | Date | Subject | |
|---|---|---|---|
| Previous Message | Hayato Kuroda (Fujitsu) | 2026-10-30 10:33:55 | RE: Fix "unexpected logical decoding status change" error; from concurrent logical decoding activation |