Re: Is WAL_DEBUG related code still relevant today?
Euler Taveira <euler@eulerto.com>
From: "Euler Taveira" <euler@eulerto.com>
To: "Peter Eisentraut" <peter@eisentraut.org>,
"Bharath Rupireddy" <bharath.rupireddyforpostgres@gmail.com>,
"PostgreSQL Hackers" <pgsql-hackers@lists.postgresql.org>
Date: 2023-12-06T12:46:09Z
Lists: pgsql-hackers
On Wed, Dec 6, 2023, at 8:27 AM, Peter Eisentraut wrote: > On 02.12.23 15:06, Bharath Rupireddy wrote: > > I enabled this code by compiling with the WAL_DEBUG macro and setting > > wal_debug GUC to on. Firstly, the compilation on Windows failed > > because XL_ROUTINE was passed inappropriately for XLogReaderAllocate() > > used. > > This kind of thing could be mostly avoided if we didn't hide all the > WAL_DEBUG behind #ifdefs. AFAICS LOCK_DEBUG also hides its GUCs behind #ifdefs. The fact that XLOG_DEBUG is a variable but seems like a constant surprises me. I would rename it to XLogDebug or xlog_debug. > in the normal case. That way, we don't need to wrap that in #ifdef > WAL_DEBUG, and the compiler can see the disabled code and make sure it > continues to build. I didn't check the LOCK_DEBUG code path to make sure it fits in the same category as WAL_DEBUG. If it does, maybe it is worth to apply the same logic there. -- Euler Taveira EDB https://www.enterprisedb.com/
Commits
-
Remove trace_recovery_messages
- c7a3e6b46d38 17.0 landed
-
Fix compilation on Windows with WAL_DEBUG
- 7d5a740331bf 13.14 landed
- c49b6cab1e66 14.11 landed
- 87ed81a8739b 15.6 landed
- 6248a2bb92cc 16.2 landed
- 7636725b922c 17.0 landed