Re: Is WAL_DEBUG related code still relevant today?
| От | Euler Taveira |
|---|---|
| Тема | Re: Is WAL_DEBUG related code still relevant today? |
| Дата | |
| Msg-id | b687d11a-3ba4-4e8c-83b4-2c4851101422@app.fastmail.com обсуждение исходный текст |
| Ответ на | Re: Is WAL_DEBUG related code still relevant today? (Peter Eisentraut <peter@eisentraut.org>) |
| Ответы |
Re: Is WAL_DEBUG related code still relevant today?
|
| Список | pgsql-hackers |
On Wed, Dec 6, 2023, at 8:27 AM, Peter Eisentraut wrote:
On 02.12.23 15:06, Bharath Rupireddy wrote:> I enabled this code by compiling with the WAL_DEBUG macro and setting> wal_debug GUC to on. Firstly, the compilation on Windows failed> because XL_ROUTINE was passed inappropriately for XLogReaderAllocate()> used.This kind of thing could be mostly avoided if we didn't hide all theWAL_DEBUG behind #ifdefs.
AFAICS LOCK_DEBUG also hides its GUCs behind #ifdefs. The fact that XLOG_DEBUG
is a variable but seems like a constant surprises me. I would rename it to
XLogDebug or xlog_debug.
in the normal case. That way, we don't need to wrap that in #ifdefWAL_DEBUG, and the compiler can see the disabled code and make sure itcontinues to build.
I didn't check the LOCK_DEBUG code path to make sure it fits in the same
category as WAL_DEBUG. If it does, maybe it is worth to apply the same logic
there.
В списке pgsql-hackers по дате отправления: