From: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
---|---|
To: | Noah Misch <noah(at)leadboat(dot)com> |
Cc: | Nathan Bossart <nathandbossart(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Is WAL_DEBUG related code still relevant today? |
Date: | 2023-12-07 11:20:30 |
Message-ID: | CALj2ACXBZ+z59QqGOs_fcdUN2rT2518vZv1W0-AS8oac9Y6_FQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Dec 4, 2023 at 12:37 AM Noah Misch <noah(at)leadboat(dot)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(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
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
From | Date | Subject | |
---|---|---|---|
Next Message | vignesh C | 2023-12-07 11:20:38 | Re: pg_upgrade and logical replication |
Previous Message | Matthias van de Meent | 2023-12-07 11:18:28 | Re: Reducing output size of nodeToString |