Re: Is WAL_DEBUG related code still relevant today?

On Thu, Dec 7, 2023 at 6:20 AM Bharath Rupireddy
<bharath(dot)rupireddyforpostgres(at)gmail(dot)com> wrote:
> 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?

I don't like the idea of removing WAL_DEBUG. I haven't used it in a
while, but I have used it, and it's been very helpful. You can for
example run a psql session and easily see what each command you type
generates in terms of WAL, without having to run pg_waldump over and
over and figure out which output is new. That's not something that I
need to do super-commonly, but I have wanted to do it for certain
projects, and I don't think that maintaining the WAL_DEBUG code in
tree is really causing us very much hassle. In fact, I'd argue that of
all of the various debugging bits that are part of the tree, WAL_DEBUG
is the most useful by a good margin. Things like OPTIMIZER_DEBUG and
LOCK_DEBUG seem to me to have much less utility. LOCK_DEBUG for
example produces a completely unworkable volume of output even for
very simple operations.

I've never been much of a believer in trace_recovery_messages, either,
but I'm somewhat sympathetic to the problem it's trying to solve. My
incremental backup patch set adds a new background process, and what
are you supposed to do if you have a problem with that process? You
can crank up the server debugging level overall, but what if you just
want the walsummarizer process, or say the walsummarizer and any
processes trying to take an incremental backup, to do super-detailed
logging? We don't have a model for that. I thought about adding
trace_walsummarizer_messages or debug_walsummarizer or something for
this exact reason, but I didn't because the existing
trace_recovery_messages setting seems like a kludge I don't want to
propagate. But that leaves me with nothing other than boosting up the
debug level for the whole server, which is an annoying thing to have
to do if you really only care about one subsystem.

I don't know what the right answer is exactly, but there should be
some way of telling the system something more fine-grained than "do
more logging" or "do a lot more logging" or "do really a lot more
logging" ...

--
Robert Haas
EDB: http://www.enterprisedb.com