Re: Fix a wal_debug crash with the new shmem allocation API

Hi,

On Thu, Oct 8, 2026 at 3:07 AM Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
>
> 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.

Thanks. Yes, this fix is better than mine. Since the wal_debug memory
context is only used while inserting WAL records, moving it to the WAL
insert working buffers initialization code is correct. The patch LGTM.

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

Moving the per-backend file flush context to the buffer pool access
init function looks good to me. Do we need to keep
BackendWritebackContext as extern? A quick check on
https://sourcegraph.com says no, but just in case any external module
needs it.

--
Bharath Rupireddy
Amazon Web Services: https://aws.amazon.com