From: | "Euler Taveira" <euler(at)eulerto(dot)com> |
---|---|
To: | "Peter Eisentraut" <peter(at)eisentraut(dot)org>, "Bharath Rupireddy" <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, "PostgreSQL Hackers" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Is WAL_DEBUG related code still relevant today? |
Date: | 2023-12-06 12:46:09 |
Message-ID: | b687d11a-3ba4-4e8c-83b4-2c4851101422@app.fastmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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/
From | Date | Subject | |
---|---|---|---|
Next Message | Zhijie Hou (Fujitsu) | 2023-12-06 12:55:29 | Forbid the use of invalidated physical slots in streaming replication. |
Previous Message | Andrew Dunstan | 2023-12-06 12:36:36 | Re: Emitting JSON to file using COPY TO |