From: | "Euler Taveira" <euler(at)eulerto(dot)com> |
---|---|
To: | "Michael Paquier" <michael(at)paquier(dot)xyz> |
Cc: | "Peter Eisentraut" <peter(at)eisentraut(dot)org>, "Bharath Rupireddy" <bharath(dot)rupireddyforpostgres(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 02:32:19 |
Message-ID: | d0433faf-b16a-4e92-acd5-f67a14a352b4@app.fastmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
EDB https://www.enterprisedb.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2023-12-07 02:40:30 | Re: Is WAL_DEBUG related code still relevant today? |
Previous Message | Amit Kapila | 2023-12-07 02:23:21 | Re: pg_upgrade and logical replication |