Neil Conway <[EMAIL PROTECTED]> writes:
> Unless anyone objects, I intend to apply this in 24 hours or so.
Patch applied.
-Neil
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Tom Lane <[EMAIL PROTECTED]> 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 commen
Neil Conway <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> 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
Tom Lane <[EMAIL PROTECTED]> 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 varia
Neil Conway <[EMAIL PROTECTED]> 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
> Shoul
Tom Lane <[EMAIL PROTECTED]> 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_lwloc
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 woul
Peter Eisentraut <[EMAIL PROTECTED]> 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
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
deb
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.
-Neil
Index: doc/src/sgml/runtime.sgml
=
10 matches
Mail list logo
