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/[email protected]. 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
v1-0001-Fix-crash-with-wal_debug-in-EXEC_BACKEND-child-pr.patch
Description: Binary data
