public inbox for [email protected]
help / color / mirror / Atom feedFrom: Michael Paquier <[email protected]>
To: Euler Taveira <[email protected]>
Cc: Peter Eisentraut <[email protected]>
Cc: Bharath Rupireddy <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: Is WAL_DEBUG related code still relevant today?
Date: Thu, 7 Dec 2023 09:51:28 +0900
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <CALj2ACVF14WKQMFwcJ=3okVDhiXpuK5f7YdT+BdYXbbypMHqWA@mail.gmail.com>
<[email protected]>
<[email protected]>
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
>> 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.
+1. Or just wal_debug for greppability.
>> 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.
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
Attachments:
[application/pgp-signature] signature.asc (833B, ../[email protected]/2-signature.asc)
download
view thread (6+ messages)
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Is WAL_DEBUG related code still relevant today?
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox