On 21/09/2026 21:56, Bharath Rupireddy wrote:
> I found a crash with WAL_DEBUG related code on HEAD. After commit
> 9b5acad3f40f converted XLOGShmemInit() to the new shared memory
> allocation API, the memory context used by wal_debug is created in the
> initialization callback, which runs only in the postmaster or in a
> standalone backend. In EXEC_BACKEND builds, child processes run the
> attach callback instead, and that one was not taught to create the
> context. Previously, XLOGShmemInit() itself ran in every child and
> created the context before returning early.
>
> As a result, with WAL_DEBUG compiled in and wal_debug turned on, a
> child process has nowhere to allocate the description of the record it
> is about to insert, and crashes on the first WAL insertion.
> Reproduction steps at [1].
Good catch, thanks.
> I propose to fix this by creating the context from both callbacks, so
> that every process ends up with one, as before. Please find the
> attached patch. I think this fix needs to be back-patched through
> PG19, where the above commit went in.
Hmm, it's a bit ugly to initialize what is a purely backend-private
thing in the ShmemInit/Attach() functions. It was expedient in the past,
because the ShmemInit() functions happened to run at the right times,
but initializing the memory context was never related to shared memory
in any way. I propose the attached, which calls the InitWalDebug()
function from InitXLogInsert() instead.
Searching for similar cases where we do backend-private initialization
that is not related to shared memory in the shmem callbacks, I found
BufferManagerShmemAttach():
> static void
> BufferManagerShmemAttach(void *arg)
> {
> /* Initialize per-backend file flush context */
> WritebackContextInit(&BackendWritebackContext,
> &backend_flush_after);
> }
There's no bug here, but I propose that we also move that to
InitBufferManagerAccess(), per the second attached patch.
- Heikki
