Feedback-ID: i0fe9450f:Fastmail
Date: Thu, 7 Dec 2023 09:51:28 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Euler Taveira <euler@eulerto.com>
Cc: 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?
Message-ID: <ZXEXEAUVFrvpquSd@paquier.xyz>
References: <CALj2ACVF14WKQMFwcJ=3okVDhiXpuK5f7YdT+BdYXbbypMHqWA@mail.gmail.com>
 <5a2e43da-0425-4fc1-9b13-19fd33123950@eisentraut.org>
 <b687d11a-3ba4-4e8c-83b4-2c4851101422@app.fastmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="b2PW6KVlSNpy6TxA"
Content-Disposition: inline
In-Reply-To: <b687d11a-3ba4-4e8c-83b4-2c4851101422@app.fastmail.com>
Archived-At: <https://www.postgresql.org/message-id/ZXEXEAUVFrvpquSd%40paquier.xyz>
Precedence: bulk


--b2PW6KVlSNpy6TxA
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Dec 06, 2023 at 09:46:09AM -0300, Euler Taveira wrote:
> On Wed, Dec 6, 2023, at 8:27 AM, Peter Eisentraut wrote:
>> This kind of thing could be mostly avoided if we didn't hide all the=20
>> WAL_DEBUG behind #ifdefs.
>=20
> 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.

+1.  Or just wal_debug for greppability.

>> in the normal case.  That way, we don't need to wrap that in #ifdef=20
>> WAL_DEBUG, and the compiler can see the disabled code and make sure it=
=20
>> continues to build.
>=20
> 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 lo=
gic
> there.

PerformWalRecovery() with its log for RM_XACT_ID is something that
stresses me a bit though because this is in the main redo loop which
is never free.  The same can be said about GenericXLogFinish() because
the extra computation happens while holding a buffer and marking it
dirty.  The ones in xlog.c are free of charge as they are called
outside any critical portions.

This makes me wonder how much we need to care about
trace_recovery_messages, actually, and I've never used it.
--
Michael

--b2PW6KVlSNpy6TxA
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmVxFxAACgkQnvQgOdby
QH3wHg//TjbTc7/1bXSnsoFl6DAeOuaF3DCKA+LtSnIjetP8m6/WrRpCigkQncg9
zeDFtLWZqhzvs4fztMDIKWwbWiz4jqh07ZZERpoE6EsEP+xxe4xL9SLmJWUJUbrn
7P7R+RQ9F5fajrvZ3oY9mnlH5c6F2ZrhuO2hRLJJjVebZagKPQQQ2/cBN6zq/Z0D
T9E6gJLb5dMwyQTJwAoPU0VpZUpKhL/dJn4SR2QkLulQMAFDwSQndQicK1v9RVx3
yTK82g0Bfn8rynwb6GhBGrDmQSMyXVXrigmk2yJAvok2/ZG7T4RMcdNfFxVAw3nP
95xBeRHg39seEMPCKqxvsEDvn17mxCm41nw/zOAZgorTx7C9w8HTT5nQxuRUfHaM
BB3ZLOIUsvmOF7Pob7qPP6s6BifqXwhrx7K6o2ai+FSTOJBKMgLktCg95OOlDXJV
s0OR1S8w4nK6bHnLpfbBF7dLS/in+RQAcMiw5hTg0Jiwc+6YQ/gAcWJhuV4EJUIC
bIEwC/x5kEFjMnn3lxuiGwcZc8aSJF6Ag2cmiFAS0EjsQYOAns//3DZvzigy06Rt
cx1WabPHAFa9eNyDVUyGusjADeiT9kizMI5rwThTNNlv80vCGGyLmNseslsmSftm
8ewXFWzyzZbZBmQ6muabrjjY1wHanWpsa9BP+7R4hTKnAy0RPTY=
=LGAq
-----END PGP SIGNATURE-----

--b2PW6KVlSNpy6TxA--