On Thu, Dec 07, 2023 at 04:50:30PM +0530, Bharath Rupireddy wrote:
> 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:
> 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.