From bc028beb166b704d3c3028961dd6905772bf3a2d Mon Sep 17 00:00:00 2001 From: Neil Conway Date: Tue, 6 Jan 2004 17:26:23 +0000 Subject: Make the 'wal_debug' GUC variable a boolean (rather than an integer), and hide it behind #ifdef WAL_DEBUG blocks. --- doc/src/sgml/ref/show.sgml | 4 ++-- doc/src/sgml/runtime.sgml | 9 ++++++--- doc/src/sgml/wal.sgml | 21 ++++++++++----------- 3 files changed, 18 insertions(+), 16 deletions(-) (limited to 'doc/src') diff --git a/doc/src/sgml/ref/show.sgml b/doc/src/sgml/ref/show.sgml index 3087c92d9e6..85dbfdcedcc 100644 --- a/doc/src/sgml/ref/show.sgml +++ b/doc/src/sgml/ref/show.sgml @@ -1,5 +1,5 @@ @@ -172,7 +172,7 @@ SHOW ALL; . . . - wal_debug | 0 + wal_debug | off wal_sync_method | fdatasync (94 rows) diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml index 6caf5dd93ac..5ec155d24d9 100644 --- a/doc/src/sgml/runtime.sgml +++ b/doc/src/sgml/runtime.sgml @@ -1,5 +1,5 @@ @@ -2667,10 +2667,13 @@ dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir' - wal_debug (integer) + wal_debug (boolean) - If nonzero, turn on WAL-related debugging output. + If true, emit WAL-related debugging output. This option is + only available if the WAL_DEBUG macro was + defined when PostgreSQL was + compiled. diff --git a/doc/src/sgml/wal.sgml b/doc/src/sgml/wal.sgml index 0883f202422..8d0127b9f94 100644 --- a/doc/src/sgml/wal.sgml +++ b/doc/src/sgml/wal.sgml @@ -1,4 +1,4 @@ - + Write-Ahead Logging (<acronym>WAL</acronym>) @@ -19,10 +19,10 @@ transaction processing. Briefly, WAL'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 + 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,7 +187,7 @@ There will be at least one 16 MB segment file, and will normally not be more than 2 * checkpoint_segments + 1 - files. You can use this to estimate space requirements for WAL. + 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 @@ -254,7 +254,7 @@ The wal_sync_method parameter determines how PostgreSQL will ask the kernel to force - WAL updates out to disk. + 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 fsync @@ -262,11 +262,10 @@ - Setting the wal_debug parameter to any nonzero - value will result in each LogInsert and + Enabling the wal_debug configuration parameter + will result in each LogInsert and LogFlush WAL 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 + logged to the server log. This option may be replaced by a more general mechanism in the future. -- cgit v1.2.3