Re: Is WAL_DEBUG related code still relevant today?
Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
From: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
To: Noah Misch <noah@leadboat.com>
Cc: Nathan Bossart <nathandbossart@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2023-12-07T11:20:30Z
Lists: pgsql-hackers
On Mon, Dec 4, 2023 at 12:37 AM Noah Misch <noah@leadboat.com> wrote: > > 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@gmail.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 Agree it helps in all of the above situations, but I'm curious to know what sorts of problems it helps debug with. The interesting pieces that WAL_DEBUG code does are the following: 1. Decodes the WAL record right after it's written to WAL buffers in XLogInsertRecord. What problem does it help to detect? 2. Emits a log message for every WAL record applied in the main redo apply loop. Enabling this isn't cheap for sure even for developer environments; I've observed a 10% increase in recovery test time) 3. Emits log messages for WAL writes/flushes and WAL buffer page initializations. These messages don't have to be hiding under a macro, but a DEBUGX level is sufficient. > > > > 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. I'm just curious to know what sorts of problems WAL_DEBUG code helps debug with. Is the WAL_DEBUG code (1) or (2) or (3) that helped you the most? Is converting the LOG messages (3) to DEBUGX level going to help in your case? Can you please throw some light on this? -- Bharath Rupireddy PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
Commits
-
Remove trace_recovery_messages
- c7a3e6b46d38 17.0 landed
-
Fix compilation on Windows with WAL_DEBUG
- 7d5a740331bf 13.14 landed
- c49b6cab1e66 14.11 landed
- 87ed81a8739b 15.6 landed
- 6248a2bb92cc 16.2 landed
- 7636725b922c 17.0 landed