Re: Is WAL_DEBUG related code still relevant today?
| От | Euler Taveira |
|---|---|
| Тема | Re: Is WAL_DEBUG related code still relevant today? |
| Дата | |
| Msg-id | d0433faf-b16a-4e92-acd5-f67a14a352b4@app.fastmail.com обсуждение исходный текст |
| Ответ на | Re: Is WAL_DEBUG related code still relevant today? (Michael Paquier <michael@paquier.xyz>) |
| Ответы |
Re: Is WAL_DEBUG related code still relevant today?
|
| Список | pgsql-hackers |
On Wed, Dec 6, 2023, at 9:51 PM, Michael Paquier wrote:
PerformWalRecovery() with its log for RM_XACT_ID is something thatstresses me a bit though because this is in the main redo loop whichis never free. The same can be said about GenericXLogFinish() becausethe extra computation happens while holding a buffer and marking itdirty. The ones in xlog.c are free of charge as they are calledoutside any critical portions.This makes me wonder how much we need to care abouttrace_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;
}
В списке pgsql-hackers по дате отправления: