make "wal_debug" GUC var a boolean

Neil Conway wrote:

The "wal_debug" GUC variable was of type "integer", but it was used
in the code effectively as a boolean: the code only tested whether it
was zero or non-zero. This patch makes it a proper boolean.

I agree with this, but would it be possible to fold it into the normal
debug output mechanisms? I don't think debugging WAL is any more
important nowadays than any other component.

Peter Eisentraut <peter_e@gmx.net> writes:

I agree with this, but would it be possible to fold it into the normal
debug output mechanisms? I don't think debugging WAL is any more
important nowadays than any other component.

I agree. Having a special debug variable for WAL seems like a
short-term thing whose time has passed. You could probably even
make that code a compile-time option like the others at the
bottom of pg_config_manual.h.

regards, tom lane

Tom Lane wrote:

I agree. Having a special debug variable for WAL seems like a
short-term thing whose time has passed. You could probably even
make that code a compile-time option like the others at the
bottom of pg_config_manual.h.

That seems right. It's never something that a user would need, because
by the time you'd tell him to turn it on, the events won't be
repeatable.

Btw., that list in pg_config_manual.h is totally incomplete and seems
unnecessary because most of these things only affect one file and are
better turned on or off there.

Tom Lane <tgl@sss.pgh.pa.us> writes:

I agree. Having a special debug variable for WAL seems like a
short-term thing whose time has passed.

ISTM that there is little distinguishing wal_debug and the following
GUC vars:

log_btree_build_stats
trace_notify
trace_locks
trace_userlocks
trace_lwlocks
debug_deadlocks
trace_lock_oidmin
trace_lock_table
debug_shared_buffers

Should these be changed as well?

-Neil

Neil Conway <neilc@samurai.com> writes:

ISTM that there is little distinguishing wal_debug and the following
GUC vars:

log_btree_build_stats
trace_notify
trace_locks
trace_userlocks
trace_lwlocks
debug_deadlocks
trace_lock_oidmin
trace_lock_table
debug_shared_buffers

Should these be changed as well?

Well, Jan just put in debug_shared_buffers recently, so I'd assume
that's still a live debugging option.

The others are already #ifdef'd out by default, which is more or
less what I was suggesting you do with the wal_debug code.

regards, tom lane

Tom Lane <tgl@sss.pgh.pa.us> writes:

The others are already #ifdef'd out by default, which is more or
less what I was suggesting you do with the wal_debug code.

(FWIW, trace_notify is not #ifdef'd out.)

But I thought that you (and Peter) were suggesting that this shouldn't
be made a GUC variable at all, just a preprocessor definition.

-Neil

Neil Conway <neilc@samurai.com> writes:

Tom Lane <tgl@sss.pgh.pa.us> writes:

The others are already #ifdef'd out by default, which is more or
less what I was suggesting you do with the wal_debug code.

(FWIW, trace_notify is not #ifdef'd out.)

My mistake --- if you feel like making it so, go to it.

But I thought that you (and Peter) were suggesting that this shouldn't
be made a GUC variable at all, just a preprocessor definition.

I think the combination of #ifdef and GUC variable is appropriate.
Just because you want to debug something doesn't necessarily mean you
want the log messages on full strength every instant, especially for
high-volume messages such as the WAL ones. You might for instance want
to log just one backend's WAL activity.

regards, tom lane

Tom Lane <tgl@sss.pgh.pa.us> writes:

I think the combination of #ifdef and GUC variable is appropriate.

The attached patch implements this: the wal_debug GUC var is now a
boolean, and is encloded in `#ifdef WAL_DEBUG` blocks (and the
WAL_DEBUG symbol is present in pg_config_manual.h, just commented
out).

Unless anyone objects, I intend to apply this in 24 hours or so.

-Neil

Neil Conway <neilc@samurai.com> writes:

Unless anyone objects, I intend to apply this in 24 hours or so.

Patch applied.

-Neil