public inbox for [email protected]
help / color / mirror / Atom feedFrom: Tom Lane <[email protected]>
To: 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: Wed, 06 Dec 2023 10:06:17 -0500
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <CALj2ACVF14WKQMFwcJ=3okVDhiXpuK5f7YdT+BdYXbbypMHqWA@mail.gmail.com>
<[email protected]>
Peter Eisentraut <[email protected]> writes:
> This kind of thing could be mostly avoided if we didn't hide all the
> WAL_DEBUG behind #ifdefs. For example, in the attached patch, I instead
> changed it so that
> if (XLOG_DEBUG)
> resolves to
> if (false)
> 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.
Hmm, maybe, but I'm not sure this would be an unalloyed good.
The main concern I have is compilers and static analyzers starting
to bleat about unreachable code (warnings like "variable set but
never used", or the like, seem plausible). The dead code would
also decrease our code coverage statistics, not that those are
wonderful now.
regards, tom lane
view thread (6+ messages) latest in thread
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]
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