Fix a wal_debug crash with the new shmem allocation API

Hi,

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

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.

Thoughts?

PS: There was an interesting discussion about enabling WAL_DEBUG on
one of the existing BF animals
https://postgr.es/m/ZW0n_A264qAQCOJu@paquier.xyz. Such coverage could
have caught this.

[1]
./configure --prefix=$PWD/inst --enable-debug --enable-cassert \
CFLAGS="-ggdb3 -O0 -DWAL_DEBUG -DEXEC_BACKEND"

SET wal_debug = ON;
CREATE TABLE t(a int);

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