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 -0000 1.226
--- doc/src/sgml/runtime.sgml 11 Dec 2003 18:46:14 -0000
***************
*** 2667,2676 ****
</varlistentry>
<varlistentry>
! <term><varname>wal_debug</varname> (<type>integer</type>)</term>
<listitem>
<para>
! If nonzero, turn on WAL-related debugging output.
</para>
</listitem>
</varlistentry>
--- 2667,2676 ----
</varlistentry>
<varlistentry>
! <term><varname>wal_debug</varname> (<type>boolean</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 -0000 1.26
--- doc/src/sgml/wal.sgml 11 Dec 2003 18:50:06 -0000
***************
*** 19,28 ****
transaction processing. Briefly, <acronym>WAL</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, <acronym>WAL</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 * <varname>checkpoint_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 * <varname>checkpoint_segments</varname> + 1
! files. You can use this to estimate space requirements for <acronym>WAL</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 <varname>wal_sync_method</varname> parameter determines how
<productname>PostgreSQL</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 <varname>fsync</varname>
--- 254,260 ----
<para>
The <varname>wal_sync_method</varname> parameter determines how
<productname>PostgreSQL</productname> will ask the kernel to force
! <acronym>WAL</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 <varname>fsync</varname>
***************
*** 262,272 ****
</para>
<para>
! Setting the <varname>wal_debug</varname> parameter to any nonzero
! value will result in each <function>LogInsert</function> and
<function>LogFlush</function> <acronym>WAL</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 the future.
</para>
</sect1>
--- 262,271 ----
</para>
<para>
! Enabling the <varname>wal_debug</varname> configuration parameter
! will result in each <function>LogInsert</function> and
<function>LogFlush</function> <acronym>WAL</acronym> call being
! logged to the server log. This option may be replaced by a more
general mechanism in the future.
</para>
</sect1>
Index: doc/src/sgml/ref/show.sgml
===================================================================
RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/ref/show.sgml,v
retrieving revision 1.34
diff -c -r1.34 show.sgml
*** doc/src/sgml/ref/show.sgml 29 Nov 2003 19:51:39 -0000 1.34
--- doc/src/sgml/ref/show.sgml 11 Dec 2003 19:43:44 -0000
***************
*** 172,178 ****
.
.
.
! wal_debug | 0
wal_sync_method | fdatasync
(94 rows)
</programlisting>
--- 172,178 ----
.
.
.
! wal_debug | off
wal_sync_method | fdatasync
(94 rows)
</programlisting>
Index: src/backend/access/transam/xlog.c
===================================================================
RCS file: /var/lib/cvs/pgsql-server/src/backend/access/transam/xlog.c,v
retrieving revision 1.126
diff -c -r1.126 xlog.c
*** src/backend/access/transam/xlog.c 29 Nov 2003 19:51:40 -0000 1.126
--- src/backend/access/transam/xlog.c 11 Dec 2003 18:40:02 -0000
***************
*** 86,92 ****
/* User-settable parameters */
int CheckPointSegments = 3;
int XLOGbuffers = 8;
! int XLOG_DEBUG = 0;
char *XLOG_sync_method = NULL;
const char XLOG_sync_method_default[] = DEFAULT_SYNC_METHOD_STR;
char XLOG_archive_dir[MAXPGPATH]; /* null string means
--- 86,92 ----
/* User-settable parameters */
int CheckPointSegments = 3;
int XLOGbuffers = 8;
! bool XLOG_DEBUG = false;
char *XLOG_sync_method = NULL;
const char XLOG_sync_method_default[] = DEFAULT_SYNC_METHOD_STR;
char XLOG_archive_dir[MAXPGPATH]; /* null string means
Index: src/backend/utils/misc/guc.c
===================================================================
RCS file: /var/lib/cvs/pgsql-server/src/backend/utils/misc/guc.c,v
retrieving revision 1.175
diff -c -r1.175 guc.c
*** src/backend/utils/misc/guc.c 3 Dec 2003 18:52:00 -0000 1.175
--- src/backend/utils/misc/guc.c 11 Dec 2003 18:45:14 -0000
***************
*** 336,352 ****
* TO ADD AN OPTION:
*
* 1. Declare a global variable of type bool, int, double, or char*
! * and make use of it.
*
* 2. Decide at what times it's safe to set the option. See guc.h for
! * details.
*
* 3. Decide on a name, a default value, upper and lower bounds (if
! * applicable), etc.
*
* 4. Add a record below.
*
! * 5. Add it to src/backend/utils/misc/postgresql.conf.sample.
*
* 6. Add it to src/bin/psql/tab-complete.c, if it's a USERSET option.
*
--- 336,353 ----
* TO ADD AN OPTION:
*
* 1. Declare a global variable of type bool, int, double, or char*
! * and make use of it.
*
* 2. Decide at what times it's safe to set the option. See guc.h for
! * details.
*
* 3. Decide on a name, a default value, upper and lower bounds (if
! * applicable), etc.
*
* 4. Add a record below.
*
! * 5. Add it to src/backend/utils/misc/postgresql.conf.sample, if
! * appropriate
*
* 6. Add it to src/bin/psql/tab-complete.c, if it's a USERSET option.
*
***************
*** 862,867 ****
--- 863,878 ----
#endif
},
+ {
+ {"wal_debug", PGC_SUSET, DEVELOPER_OPTIONS,
+ gettext_noop("Emit WAL-related debugging output."),
+ NULL,
+ GUC_NOT_IN_SAMPLE
+ },
+ &XLOG_DEBUG,
+ false, NULL, NULL
+ },
+
/* End-of-list marker */
{
{NULL, 0, 0, NULL, NULL}, NULL, false, NULL, NULL
***************
*** 1172,1187 ****
},
{
- {"wal_debug", PGC_SUSET, DEVELOPER_OPTIONS,
- gettext_noop("If nonzero, WAL-related debugging output is logged."),
- NULL,
- GUC_NOT_IN_SAMPLE
- },
- &XLOG_DEBUG,
- 0, 0, 16, NULL, NULL
- },
-
- {
{"commit_delay", PGC_USERSET, WAL_CHECKPOINTS,
gettext_noop("Sets the delay in microseconds between transaction commit and "
"flushing WAL to disk."),
--- 1183,1188 ----
Index: src/include/access/xlog.h
===================================================================
RCS file: /var/lib/cvs/pgsql-server/src/include/access/xlog.h,v
retrieving revision 1.45
diff -c -r1.45 xlog.h
*** src/include/access/xlog.h 29 Nov 2003 22:40:55 -0000 1.45
--- src/include/access/xlog.h 11 Dec 2003 18:39:32 -0000
***************
*** 189,195 ****
extern int CheckPointSegments;
extern int CheckPointWarning;
extern int XLOGbuffers;
! extern int XLOG_DEBUG;
extern char *XLOG_sync_method;
extern const char XLOG_sync_method_default[];
--- 189,195 ----
extern int CheckPointSegments;
extern int CheckPointWarning;
extern int XLOGbuffers;
! extern bool XLOG_DEBUG;
extern char *XLOG_sync_method;
extern const char XLOG_sync_method_default[];
---------------------------(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
