Feedback-ID: i0c21471d:Fastmail
User-Agent: Cyrus-JMAP/3.9.0-alpha0-1178-geeaf0069a7-fm-20231114.001-geeaf0069
MIME-Version: 1.0
Message-Id: <b687d11a-3ba4-4e8c-83b4-2c4851101422@app.fastmail.com>
In-Reply-To: <5a2e43da-0425-4fc1-9b13-19fd33123950@eisentraut.org>
References: 
 <CALj2ACVF14WKQMFwcJ=3okVDhiXpuK5f7YdT+BdYXbbypMHqWA@mail.gmail.com>
 <5a2e43da-0425-4fc1-9b13-19fd33123950@eisentraut.org>
Date: Wed, 06 Dec 2023 09:46:09 -0300
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>
Subject: Re: Is WAL_DEBUG related code still relevant today?
Content-Type: multipart/alternative;
 boundary=168f2e2acb534bdcb570f882947d86e9
Archived-At: <https://www.postgresql.org/message-id/b687d11a-3ba4-4e8c-83b4-2c4851101422%40app.fastmail.com>
Precedence: bulk

--168f2e2acb534bdcb570f882947d86e9
Content-Type: text/plain

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/

--168f2e2acb534bdcb570f882947d86e9
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title><style type=3D"text/css">p.Mso=
Normal,p.MsoNoSpacing{margin:0}</style></head><body><div>On Wed, Dec 6, =
2023, at 8:27 AM, Peter Eisentraut wrote:<br></div><blockquote type=3D"c=
ite" id=3D"qt" style=3D""><div>On 02.12.23 15:06, Bharath Rupireddy wrot=
e:<br></div><div>&gt; I enabled this code by compiling with the WAL_DEBU=
G macro and setting<br></div><div>&gt; wal_debug GUC to on. Firstly, the=
 compilation on Windows failed<br></div><div>&gt; because XL_ROUTINE was=
 passed inappropriately for XLogReaderAllocate()<br></div><div>&gt; used=
.<br></div><div><br></div><div>This kind of thing could be mostly avoide=
d if we didn't hide all the&nbsp;<br></div><div>WAL_DEBUG behind #ifdefs=
.<br></div></blockquote><div><br></div><div>AFAICS LOCK_DEBUG also hides=
 its GUCs behind #ifdefs. The fact that XLOG_DEBUG<br></div><div>is a va=
riable but seems like a constant surprises me. I would rename it to<br><=
/div><div>XLogDebug or xlog_debug.<br></div><div><br></div><blockquote t=
ype=3D"cite" id=3D"qt" style=3D""><div>in the normal case.&nbsp; That wa=
y, we don't need to wrap that in #ifdef&nbsp;<br></div><div>WAL_DEBUG, a=
nd the compiler can see the disabled code and make sure it&nbsp;<br></di=
v><div>continues to build.<br></div></blockquote><div><br></div><div>I d=
idn't check the LOCK_DEBUG code path to make sure it fits in the same<br=
></div><div>category as WAL_DEBUG. If it does, maybe it is worth to appl=
y the same logic<br></div><div>there.<br></div><div><br></div><div><br><=
/div><div id=3D"sig112409080"><div class=3D"signature">--<br></div><div =
class=3D"signature">Euler Taveira<br></div><div class=3D"signature">EDB&=
nbsp;&nbsp; <a href=3D"https://www.enterprisedb.com/">https://www.enterp=
risedb.com/</a><br></div></div><div><br></div></body></html>
--168f2e2acb534bdcb570f882947d86e9--