Track which shmem areas have been fully initialized If SHMEM_CALLBACKS_ALLOW_AFTER_STARTUP is used to allocate shared memory after startup, but the initialization fails half-way through, the shmem area is left in an indeterminate state. Furthermore, if multiple shmem areas are registered in one RegisterShmemCallbacks() call, some might be allocated while others are not.
This commit adds an explicit 'initialized' flag to each shmem area. We still leave behind an uninitialized area on error, but at least they are now clearly marked, and you get a slightly nicer error message if you try to re-register them. It'd be nice to clean up more thoroughly and support actually retrying the allocations, but in practice, the most likely reason for a shmem allocation or initialization to fail is that you are out of shared memory and retrying wouldn't help with that. This isn't exactly a new problem, the old ShmemInitStruct() interface had similar issues if the initialization code failed, or if you allocated multiple structs and some allocations failed. It was just left to the calling code to deal with it. Author: Ayush Tiwari <[email protected]> Reviewed-by: Ashutosh Bapat <[email protected]> Discussion: https://www.postgresql.org/message-id/CAJTYsWVRRWH48=pcuao_2y4ap6m0qrmzxguffknrtdwk74l...@mail.gmail.com Backpatch-through: 19 Branch ------ REL_19_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/9d888cd3f34c4e9a8f7fbe7e78c70bbd84a481de Modified Files -------------- doc/src/sgml/xfunc.sgml | 5 +- src/backend/storage/ipc/shmem.c | 67 ++++++++++++++++++++-- src/test/modules/test_shmem/Makefile | 3 + src/test/modules/test_shmem/meson.build | 3 + .../modules/test_shmem/t/001_late_shmem_alloc.pl | 50 ++++++++++++++-- src/test/modules/test_shmem/test_shmem.c | 3 + 6 files changed, 120 insertions(+), 11 deletions(-)
