On Thu, Dec 7, 2023 at 6:20 AM Bharath Rupireddy <bharath.rupireddyforpostg...@gmail.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
