Subject: Re: Is WAL_DEBUG related code still relevant today?

From: "Euler Taveira" <[email-masked]>
Date: Wed, 06 Dec 2023 23:32:19 -0300

On Wed, Dec 6, 2023, at 9:51 PM, Michael Paquier wrote:
> PerformWalRecovery() with its log for RM_XACT_ID is something that
> stresses me a bit though because this is in the main redo loop which
> is never free.  The same can be said about GenericXLogFinish() because
> the extra computation happens while holding a buffer and marking it
> dirty.  The ones in xlog.c are free of charge as they are called
> outside any critical portions.
> 
> This makes me wonder how much we need to care about
> trace_recovery_messages, actually, and I've never used it.

IIUC trace_recovery_messages was a debugging aid in the 9.0 era when the HS was
introduced. I'm also wondering if anyone used it in the past years.

elog.c:

* Intention is to keep this for at least the whole of the 9.0 production
* release, so we can more easily diagnose production problems in the field.
* It should go away eventually, though, because it's an ugly and
* hard-to-explain kluge.
*/
int
trace_recovery(int trace_level)
{
    if (trace_level < LOG &&
        trace_level >= trace_recovery_messages)
        return LOG; 

    return trace_level;
}

--
Euler Taveira
EDB   https://www.enterprisedb.com/

---

From: Michael Paquier <[email-masked]>
Date: Thu, 7 Dec 2023 11:40:30 +0900

> introduced. I'm also wondering if anyone used it in the past years.

FWIW, I'd be +1 for getting rid of entirely, with its conditional
block in PerformWalRecovery(), as it does not bring any additional
value now that it is possible to achieve much more with pg_waldump
(pg_xlogdump before that) introduced a couple of years later in 9.3.
--
Michael