Re: [PATCHES] make wal_debug GUC var a boolean

2003-12-12 Thread Neil Conway 
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_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

Re: [PATCHES] make wal_debug GUC var a boolean

2003-12-12 Thread Neil Conway 
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 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

Re: [PATCHES] make wal_debug GUC var a boolean

2003-12-12 Thread Tom Lane 
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, 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

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly

[PATCHES] make wal_debug GUC var a boolean

2003-12-11 Thread Neil Conway 
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
===
RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/runtime.sgml,v
retrieving revision 1.226
diff -c -r1.226 runtime.sgml
*** doc/src/sgml/runtime.sgml	6 Dec 2003 23:10:23 -	1.226
--- doc/src/sgml/runtime.sgml	11 Dec 2003 18:46:14 -
***
*** 2667,2676 
   /varlistentry
  
   varlistentry
!   termvarnamewal_debug/varname (typeinteger/type)/term
listitem
 para
! If nonzero, turn on WAL-related debugging output.
 /para
/listitem
   /varlistentry
--- 2667,2676 
   /varlistentry
  
   varlistentry
!   termvarnamewal_debug/varname (typeboolean/type)/term
listitem
 para
! If true, emit WAL-related debugging output.
 /para
/listitem
   /varlistentry
Index: doc/src/sgml/wal.sgml
===
RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/wal.sgml,v
retrieving revision 1.26
diff -c -r1.26 wal.sgml
*** doc/src/sgml/wal.sgml	29 Nov 2003 19:51:38 -	1.26
--- doc/src/sgml/wal.sgml	11 Dec 2003 18:50:06 -
***
*** 19,28 
 transaction processing. Briefly, acronymWAL/acronym's central
 concept is that changes to data files (where tables and indexes
 reside) must be written only after those changes have been logged,
!that is, when log records have been flushed to permanent
!storage. If we follow this procedure, we do not need to flush
!data pages to disk on every transaction commit, because we know
!that in the event of a crash we will be able to recover the
 database using the log: any changes that have not been applied to
 the data pages will first be redone from the log records (this is
 roll-forward recovery, also known as REDO) and then changes made by
--- 19,28 
 transaction processing. Briefly, acronymWAL/acronym's central
 concept is that changes to data files (where tables and indexes
 reside) must be written only after those changes have been logged,
!that is, when log records describing the changes have been flushed
!to permanent storage. If we follow this procedure, we do not need
!to flush data pages to disk on every transaction commit, because we
!know that in the event of a crash we will be able to recover the
 database using the log: any changes that have not been applied to
 the data pages will first be redone from the log records (this is
 roll-forward recovery, also known as REDO) and then changes made by
***
*** 187,193 
para
 There will be at least one 16 MB segment file, and will normally
 not be more than 2 * varnamecheckpoint_segments/varname + 1
!files.  You can use this to estimate space requirements for WAL.
 Ordinarily, when old log segment files are no longer needed, they
 are recycled (renamed to become the next segments in the numbered
 sequence). If, due to a short-term peak of log output rate, there
--- 187,193 
para
 There will be at least one 16 MB segment file, and will normally
 not be more than 2 * varnamecheckpoint_segments/varname + 1
!files.  You can use this to estimate space requirements for acronymWAL/acronym.
 Ordinarily, when old log segment files are no longer needed, they
 are recycled (renamed to become the next segments in the numbered
 sequence). If, due to a short-term peak of log output rate, there
***
*** 254,260 
para
 The varnamewal_sync_method/varname parameter determines how
 productnamePostgreSQL/productname will ask the kernel to force
! WAL updates out to disk. 
 All the options should be the same as far as reliability goes,
 but it's quite platform-specific which one will be the fastest.
 Note that this parameter is irrelevant if varnamefsync/varname
--- 254,260 
para
 The varnamewal_sync_method/varname parameter determines how
 productnamePostgreSQL/productname will ask the kernel to force
! acronymWAL/acronym updates out to disk. 
 All the options should be the same as far as reliability goes,
 but it's quite platform-specific which one will be the fastest.
 Note that this parameter is irrelevant if varnamefsync/varname
***
*** 262,272 
/para
  
para
!Setting the varnamewal_debug/varname parameter to any nonzero
!value will result in each functionLogInsert/function and
 functionLogFlush/function acronymWAL/acronym call being
!logged to the server log.  At present, it makes no difference what
!the nonzero value is.  This option may be replaced by a more
 general mechanism in