Re: Is WAL_DEBUG related code still relevant today? - Mailing list pgsql-hackers

From Euler Taveira
Subject Re: Is WAL_DEBUG related code still relevant today?
Date
Msg-id d0433faf-b16a-4e92-acd5-f67a14a352b4@app.fastmail.com
Whole thread Raw
In response to Re: Is WAL_DEBUG related code still relevant today?  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Is WAL_DEBUG related code still relevant today?
List pgsql-hackers
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

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: pg_upgrade and logical replication
Next
From: Michael Paquier
Date:
Subject: Re: Is WAL_DEBUG related code still relevant today?