Re: Is WAL_DEBUG related code still relevant today?

On Sun, Dec 03, 2023 at 08:30:24PM +0530, Bharath Rupireddy wrote:
> On Sun, Dec 3, 2023 at 4:00 AM Nathan Bossart <nathandbossart(at)gmail(dot)com> wrote:
> > On Sat, Dec 02, 2023 at 07:36:29PM +0530, Bharath Rupireddy wrote:
> > > b) Remove both the WAL_DEBUG macro and the wal_debug GUC. I don't
> > > think (2) is needed to be in core especially when tools like
> > > pg_walinspect and pg_waldump can do the same job. And, the messages in
> > > (3) and (4) can be turned to some DEBUGX level without being under the
> > > WAL_DEBUG macro.
> >
> > Is there anything provided by wal_debug that can't be found via
> > pg_walinspect/pg_waldump?
>
> I don't think so. The WAL record decoding can be achieved with
> pg_walinspect or pg_waldump.

Can be, but the WAL_DEBUG model is mighty convenient:
- Cooperates with backtrace_functions
- Change log_line_prefix to correlate any log_line_prefix fact with WAL records
- See WAL records interleaved with non-WAL log messages

> > > I have no idea if anyone uses WAL_DEBUG macro and wal_debug GUCs in
> > > production, if we have somebody using it, I think we need to fix the

I don't use it in production, but I use it more than any other of our many
DEBUG macros.

> > > compilation and test failure issues, and start testing this code
> > > (perhaps I can think of setting up a buildfarm member to help here).

WAL_DEBUG compiles and works just fine on GNU/Linux. I'm not surprised the
failure to compile on Windows has escaped notice, because Windows-specific WAL
behaviors are so rare. We consistently do our WAL-related development on
non-Windows. Needless to say, I wouldn't object to fixing WAL_DEBUG for
Windows.

Fixing tests is less valuable, especially since it's clear when a test fails
through extra messages the test didn't expect. I bet other DEBUG macros make
some tests fail that way, which doesn't devalue those macros. A test patch
might be okay nonetheless, but a buildfarm member is more likely to have
negative value. It would create urgent work. In the hypothetical buildfarm
member's absence, the project would be just fine if that work never happens.
A buildfarm member that compiles but doesn't test could be okay.