On Thu, Dec 07, 2023 at 04:50:30PM +0530, Bharath Rupireddy wrote: > On Mon, Dec 4, 2023 at 12:37 AM Noah Misch <n...@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 <nathandboss...@gmail.com> > > > wrote: > > > > On Sat, Dec 02, 2023 at 07:36:29PM +0530, Bharath Rupireddy wrote:
> 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? I think it helped me understand why a test case I was writing didn't reach the bug I expected it to reach. > 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? For me, (1) and (2) came up several times, and (3) came up once. I don't remember which of (1) or (2) helped more. > Is converting the LOG messages (3) to DEBUGX level going to > help in your case? Not in my case.