Neil Conway wrote:
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.


---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

Peter Eisentraut <peter_e (AT) gmx (DOT) net> writes:
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

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo (AT) postgresql (DOT) org)

Tom Lane wrote:
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.


---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

Tom Lane <tgl (AT) sss (DOT) pgh.pa.us> 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?

-Neil


---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

Neil Conway <neilc (AT) samurai (DOT) com> writes:
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

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

Tom Lane <tgl (AT) sss (DOT) pgh.pa.us> writes:
(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


---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

Neil Conway <neilc (AT) samurai (DOT) com> writes:
My mistake --- if you feel like making it so, go to it.

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

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo (AT) postgresql (DOT) org so that your
message can get through to the mailing list cleanly

Neil Conway <neilc (AT) samurai (DOT) com> writes:
Patch applied.

-Neil


---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings