Refer to GUC variables using <xref> tags rather than <varname> tags,

where appropriate. Add "id" and "xreflabel" tags to the descriptions
of the GUC variables to facilitate this. Also make a few minor docs
cleanups.
This commit is contained in:
Neil Conway 2004-03-09 16:57:47 +00:00
parent 8567bb2d06
commit 80ec228389
21 changed files with 344 additions and 303 deletions

View File

@ -1,5 +1,5 @@
<!--
$PostgreSQL: pgsql/doc/src/sgml/backup.sgml,v 2.37 2004/02/17 23:56:07 neilc Exp $
$PostgreSQL: pgsql/doc/src/sgml/backup.sgml,v 2.38 2004/03/09 16:57:46 neilc Exp $
-->
<chapter id="backup">
<title>Backup and Restore</title>
@ -156,8 +156,8 @@ pg_dump -h <replaceable>host1</> <replaceable>dbname</> | psql -h <replaceable>h
<tip>
<para>
Restore performance can be improved by increasing the
configuration parameter <varname>maintenance_work_mem</varname>
(see <xref linkend="runtime-config-resource-memory">).
configuration parameter <xref
linkend="guc-maintenance-work-mem">.
</para>
</tip>
</sect2>

View File

@ -1,4 +1,4 @@
<!-- $PostgreSQL: pgsql/doc/src/sgml/charset.sgml,v 2.42 2003/12/30 23:36:19 tgl Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/charset.sgml,v 2.43 2004/03/09 16:57:46 neilc Exp $ -->
<chapter id="charset">
<title>Localization</>
@ -795,23 +795,23 @@ RESET client_encoding;
<listitem>
<para>
Using <envar>PGCLIENTENCODING</envar>.
If environment variable <envar>PGCLIENTENCODING</envar> is defined
in the client's environment, that client encoding is automatically
selected when a connection to the server is made. (This can subsequently
be overridden using any of the other methods mentioned above.)
Using <envar>PGCLIENTENCODING</envar>. If environment variable
<envar>PGCLIENTENCODING</envar> is defined in the client's
environment, that client encoding is automatically selected
when a connection to the server is made. (This can
subsequently be overridden using any of the other methods
mentioned above.)
</para>
</listitem>
<listitem>
<para>
Using the configuration variable <varname>client_encoding</varname>.
If the <varname>client_encoding</> variable in <filename>postgresql.conf</> is set, that
client encoding is automatically selected when a connection to the
server is made. (This can subsequently be overridden using any of the
other methods mentioned above.)
Using the configuration variable <xref
linkend="guc-client-encoding">. If the
<varname>client_encoding</> variable is set, that client
encoding is automatically selected when a connection to the
server is made. (This can subsequently be overridden using any
of the other methods mentioned above.)
</para>
</listitem>

View File

@ -1,5 +1,5 @@
<!--
$PostgreSQL: pgsql/doc/src/sgml/client-auth.sgml,v 1.63 2004/01/26 05:35:15 momjian Exp $
$PostgreSQL: pgsql/doc/src/sgml/client-auth.sgml,v 1.64 2004/03/09 16:57:46 neilc Exp $
-->
<chapter id="client-authentication">
@ -113,8 +113,8 @@ hostnossl <replaceable>database</replaceable> <replaceable>user</replaceable>
<para>
This record matches connection attempts made using TCP/IP.
Note that TCP/IP connections are disabled unless the server is
started with the <option>-i</option> option or the
<varname>tcpip_socket</> configuration parameter is
started with the <option>-i</option> option or the <xref
linkend="guc-tcpip-socket"> configuration parameter is
enabled. <literal>host</literal> records match either
<acronym>SSL</acronym> or non-<acronym>SSL</acronym> connection
attempts.
@ -134,8 +134,8 @@ hostnossl <replaceable>database</replaceable> <replaceable>user</replaceable>
<para>
To make use of this option the server must be built with
<acronym>SSL</acronym> support enabled. Furthermore,
<acronym>SSL</acronym> must be enabled by setting the
<varname>ssl</varname> configuration parameter (see <xref
<acronym>SSL</acronym> must be enabled by setting the <xref
linkend="guc-ssl"> configuration parameter (see <xref
linkend="ssl-tcp"> for more information).
</para>
</listitem>
@ -677,14 +677,14 @@ local db1,db2,@demodbs all md5
</para>
<para>
Make sure that your server key file is readable (and preferably only
readable) by the <productname>PostgreSQL</productname> server
account. (See also <xref linkend="postgres-user">). The location of the
key file is specified with the <varname>krb_server_keyfile</> run-time
configuration parameter. (See also <xref
linkend="runtime-config">.) The default is <filename>/etc/srvtab</>
if you are using Kerberos 4 and
<filename>FILE:/usr/local/pgsql/etc/krb5.keytab</> (or whichever
Make sure that your server key file is readable (and preferably
only readable) by the <productname>PostgreSQL</productname> server
account. (See also <xref linkend="postgres-user">). The location
of the key file is specified by the <xref
linkend="guc-krb-server-keyfile"> run-time configuration
parameter. (See also <xref linkend="runtime-config">.) The default
is <filename>/etc/srvtab</> if you are using Kerberos 4 and
<filename>/usr/local/pgsql/etc/krb5.keytab</> (or whichever
directory was specified as <varname>sysconfdir</> at build time)
with Kerberos 5.
</para>

View File

@ -1,5 +1,5 @@
<!--
$PostgreSQL: pgsql/doc/src/sgml/datatype.sgml,v 1.142 2004/02/01 06:55:07 tgl Exp $
$PostgreSQL: pgsql/doc/src/sgml/datatype.sgml,v 1.143 2004/03/09 16:57:46 neilc Exp $
-->
<chapter id="datatype">
@ -1409,7 +1409,7 @@ SELECT b, char_length(b) FROM test2;
traditional <productname>POSTGRES</productname>, and others.
For some formats, ordering of month, day, and year in date input is
ambiguous and there is support for specifying the expected
ordering of these fields. Set the <varname>datestyle</> parameter
ordering of these fields. Set the <xref linkend="guc-datestyle"> parameter
to <literal>MDY</> to select month-day-year interpretation,
<literal>DMY</> to select day-month-year interpretation, or
<literal>YMD</> to select year-month-day interpretation.
@ -1720,7 +1720,7 @@ January 8 04:05:06 1999 PST
time zone specified is converted to UTC using the appropriate offset
for that time zone. If no time zone is stated in the input string,
then it is assumed to be in the time zone indicated by the system's
<varname>timezone</> parameter, and is converted to UTC using the
<xref linkend="guc-timezone"> parameter, and is converted to UTC using the
offset for the <varname>timezone</> zone.
</para>
@ -1993,8 +1993,8 @@ January 8 04:05:06 1999 PST
<para>
The date/time styles can be selected by the user using the
<command>SET datestyle</command> command, the
<varname>datestyle</varname> parameter in the
<command>SET datestyle</command> command, the <xref
linkend="guc-datestyle"> parameter in the
<filename>postgresql.conf</filename> configuration file, or the
<envar>PGDATESTYLE</envar> environment variable on the server or
client. The formatting function <function>to_char</function>
@ -2092,8 +2092,8 @@ January 8 04:05:06 1999 PST
<listitem>
<para>
The <varname>timezone</varname> configuration parameter can be
set in the file <filename>postgresql.conf</>.
The <xref linkend="guc-timezone"> configuration parameter can
be set in the file <filename>postgresql.conf</>.
</para>
</listitem>
@ -2929,7 +2929,7 @@ SELECT * FROM test;
<productname>PostgreSQL</productname> as primary keys for various
system tables. An OID system column is also added to user-created
tables, unless <literal>WITHOUT OIDS</literal> is specified when
the table is created, or the <varname>default_with_oids</varname>
the table is created, or the <xref linkend="guc-default-with-oids">
configuration variable is set to false. Type <type>oid</>
represents an object identifier. There are also several alias
types for <type>oid</>: <type>regproc</>, <type>regprocedure</>,

View File

@ -1,5 +1,5 @@
<!--
$PostgreSQL: pgsql/doc/src/sgml/func.sgml,v 1.192 2004/03/07 01:01:44 neilc Exp $
$PostgreSQL: pgsql/doc/src/sgml/func.sgml,v 1.193 2004/03/09 16:57:46 neilc Exp $
PostgreSQL documentation
-->
@ -311,7 +311,7 @@ PostgreSQL documentation
returns true if <replaceable>expression</replaceable> evaluates to
the null value. It is highly recommended that these applications
be modified to comply with the SQL standard. However, if that
cannot be done the <varname>transform_null_equals</varname>
cannot be done the <xref linkend="guc-transform-null-equals">
configuration variable is available. If it is enabled,
<productname>PostgreSQL</productname> will convert <literal>x =
NULL</literal> clauses to <literal>x IS NULL</literal>. This was
@ -2715,12 +2715,12 @@ substring('foobar' from 'o(.)b') <lineannotation>o</lineannotation>
<note>
<para>
The form of regular expressions accepted by <productname>PostgreSQL</>
can be chosen by setting the <varname>regex_flavor</> run-time parameter
(described in <xref linkend="runtime-config">). The usual setting is
<literal>advanced</>, but one might choose <literal>extended</> for
maximum backwards compatibility with pre-7.4 releases of
<productname>PostgreSQL</>.
The form of regular expressions accepted by
<productname>PostgreSQL</> can be chosen by setting the <xref
linkend="guc-regex-flavor"> run-time parameter. The usual
setting is <literal>advanced</>, but one might choose
<literal>extended</> for maximum backwards compatibility with
pre-7.4 releases of <productname>PostgreSQL</>.
</para>
</note>

View File

@ -1,5 +1,5 @@
<!--
$PostgreSQL: pgsql/doc/src/sgml/perform.sgml,v 1.41 2004/02/03 17:34:02 tgl Exp $
$PostgreSQL: pgsql/doc/src/sgml/perform.sgml,v 1.42 2004/03/09 16:57:46 neilc Exp $
-->
<chapter id="performance-tips">
@ -508,7 +508,7 @@ SELECT * FROM a, b, c WHERE a.id = b.id AND b.ref = c.id;
<productname>PostgreSQL</productname> planner will switch from exhaustive
search to a <firstterm>genetic</firstterm> probabilistic search
through a limited number of possibilities. (The switch-over threshold is
set by the <varname>geqo_threshold</varname> run-time
set by the <xref linkend="guc-geqo-threshold"> run-time
parameter.)
The genetic search takes less time, but it won't
necessarily find the best possible plan.
@ -549,7 +549,7 @@ SELECT * FROM a JOIN (b JOIN c ON (b.ref = c.id)) ON (a.id = b.id);
<para>
To force the planner to follow the <literal>JOIN</> order for inner joins,
set the <varname>join_collapse_limit</> run-time parameter to 1.
set the <xref linkend="guc-join-collapse-limit"> run-time parameter to 1.
(Other possible values are discussed below.)
</para>
@ -599,8 +599,8 @@ SELECT * FROM x, y, a, b, c WHERE something AND somethingelse;
problem replacing two separate three-way join problems. Because of the
exponential growth of the number of possibilities, this makes a big
difference. The planner tries to avoid getting stuck in huge join search
problems by not collapsing a subquery if more than
<varname>from_collapse_limit</> <literal>FROM</> items would result in the parent
problems by not collapsing a subquery if more than <xref linkend="guc-from-collapse-limit">
<literal>FROM</> items would result in the parent
query. You can trade off planning time against quality of plan by
adjusting this run-time parameter up or down.
</para>
@ -688,11 +688,11 @@ SELECT * FROM x, y, a, b, c WHERE something AND somethingelse;
<title>Increase <varname>maintenance_work_mem</varname></title>
<para>
Temporarily increasing the <varname>maintenance_work_mem</varname>
Temporarily increasing the <xref linkend="guc-maintenance-work-mem">
configuration variable when restoring large amounts of data can
lead to improved performance. This is because when a B-tree index
is created from scratch, the existing content of the table needs
to be sorted. Allowing the merge sort to use more memory
to be sorted. Allowing the external merge sort to use more memory
means that fewer merge passes will be required. A larger setting for
<varname>maintenance_work_mem</varname> may also speed up validation
of foreign-key constraints.

View File

@ -1,5 +1,5 @@
<!--
$PostgreSQL: pgsql/doc/src/sgml/problems.sgml,v 2.17 2003/12/14 00:05:29 neilc Exp $
$PostgreSQL: pgsql/doc/src/sgml/problems.sgml,v 2.18 2004/03/09 16:57:46 neilc Exp $
-->
<sect1 id="bug-reporting">
@ -173,7 +173,7 @@ $PostgreSQL: pgsql/doc/src/sgml/problems.sgml,v 2.17 2003/12/14 00:05:29 neilc E
form of the message. In <application>psql</>, say <literal>\set
VERBOSITY verbose</> beforehand. If you are extracting the message
from the server log, set the run-time parameter
<varname>log_error_verbosity</> to <literal>verbose</> so that all
<xref linkend="guc-log-error-verbosity"> to <literal>verbose</> so that all
details are logged.
</para>
</note>

View File

@ -1,4 +1,4 @@
<!-- $PostgreSQL: pgsql/doc/src/sgml/protocol.sgml,v 1.49 2003/12/14 00:10:32 neilc Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/protocol.sgml,v 1.50 2004/03/09 16:57:46 neilc Exp $ -->
<chapter id="protocol">
<title>Frontend/Backend Protocol</title>
@ -390,12 +390,13 @@
<ListItem>
<Para>
This message informs the frontend about the current (initial)
setting of backend parameters, such as <varname>client_encoding</>
or <varname>DateStyle</>. The frontend may ignore this message,
or record the settings for its future use; see
<xref linkend="protocol-async"> for more detail.
The frontend should not respond to this message, but should
continue listening for a ReadyForQuery message.
setting of backend parameters, such as <xref
linkend="guc-client-encoding"> or <xref linkend="guc-datestyle">.
The frontend may ignore this message, or record the settings
for its future use; see <xref linkend="protocol-async"> for
more details. The frontend should not respond to this
message, but should continue listening for a ReadyForQuery
message.
</Para>
</ListItem>
</VarListEntry>

View File

@ -1,5 +1,5 @@
<!--
$PostgreSQL: pgsql/doc/src/sgml/ref/alter_table.sgml,v 1.65 2004/03/01 17:58:39 neilc Exp $
$PostgreSQL: pgsql/doc/src/sgml/ref/alter_table.sgml,v 1.66 2004/03/09 16:57:47 neilc Exp $
PostgreSQL documentation
-->
@ -123,6 +123,11 @@ ALTER TABLE <replaceable class="PARAMETER">name</replaceable>
</varlistentry>
<varlistentry>
<indexterm>
<primary>TOAST</primary>
<secondary>per-column storage settings</secondary>
</indexterm>
<term><literal>SET STORAGE</literal></term>
<listitem>
<para>
@ -240,7 +245,7 @@ ALTER TABLE <replaceable class="PARAMETER">name</replaceable>
to be altered, but in the current version, this is the default
behavior. (In releases before 7.1, <literal>ONLY</> was the
default behavior. The default can be altered by changing the
configuration parameter <varname>sql_inheritance</varname>.)
configuration parameter <xref linkend="guc-sql-inheritance">.)
</para>
</listitem>
</varlistentry>

View File

@ -1,5 +1,5 @@
<!--
$PostgreSQL: pgsql/doc/src/sgml/ref/analyze.sgml,v 1.18 2003/12/14 00:15:03 neilc Exp $
$PostgreSQL: pgsql/doc/src/sgml/ref/analyze.sgml,v 1.19 2004/03/09 16:57:47 neilc Exp $
PostgreSQL documentation
-->
@ -134,7 +134,7 @@ ANALYZE [ VERBOSE ] [ <replaceable class="PARAMETER">table</replaceable> [ (<rep
<para>
The extent of analysis can be controlled by adjusting the
<varname>default_statistics_target</varname> parameter variable, or
<xref linkend="guc-default-statistics-target"> configuration variable, or
on a column-by-column basis by setting the per-column statistics
target with <command>ALTER TABLE ... ALTER COLUMN ... SET
STATISTICS</command> (see <xref linkend="sql-altertable"

View File

@ -1,4 +1,4 @@
<!-- $PostgreSQL: pgsql/doc/src/sgml/ref/checkpoint.sgml,v 1.11 2003/11/29 19:51:38 pgsql Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/ref/checkpoint.sgml,v 1.12 2004/03/09 16:57:47 neilc Exp $ -->
<refentry id="sql-checkpoint">
<refmeta>
@ -27,11 +27,11 @@ CHECKPOINT
<para>
Write-Ahead Logging (WAL) puts a checkpoint in the transaction log
every so often. (To adjust the automatic checkpoint interval, see
the run-time
configuration options <varname>checkpoint_segments</varname>
and <varname>checkpoint_timeout</varname>.)
The <command>CHECKPOINT</command> command forces an immediate checkpoint
when the command is issued, without waiting for a scheduled checkpoint.
the run-time configuration options <xref linkend="guc-checkpoint-segments">
and <xref linkend="guc-checkpoint-timeout">.) The
<command>CHECKPOINT</command> command forces an immediate
checkpoint when the command is issued, without waiting for a
scheduled checkpoint.
</para>
<para>

View File

@ -1,5 +1,5 @@
<!--
$PostgreSQL: pgsql/doc/src/sgml/ref/create_table.sgml,v 1.78 2004/03/01 17:58:39 neilc Exp $
$PostgreSQL: pgsql/doc/src/sgml/ref/create_table.sgml,v 1.79 2004/03/09 16:57:47 neilc Exp $
PostgreSQL documentation
-->
@ -249,7 +249,7 @@ and <replaceable class="PARAMETER">table_constraint</replaceable> is:
should have OIDs (object identifiers) assigned to them. If
neither <literal>WITH OIDS</literal> nor <literal>WITHOUT
OIDS</literal> is specified, the default value depends upon the
<varname>default_with_oids</varname> configuration parameter. (If
<xref linkend="guc-default-with-oids"> configuration parameter. (If
the new table inherits from any tables that have OIDs, then
<literal>WITH OIDS</> is forced even if the command says
<literal>WITHOUT OIDS</>.)

View File

@ -1,5 +1,5 @@
<!--
$PostgreSQL: pgsql/doc/src/sgml/ref/create_table_as.sgml,v 1.20 2004/01/10 23:28:44 neilc Exp $
$PostgreSQL: pgsql/doc/src/sgml/ref/create_table_as.sgml,v 1.21 2004/03/09 16:57:47 neilc Exp $
PostgreSQL documentation
-->
@ -106,7 +106,7 @@ CREATE [ [ GLOBAL | LOCAL ] { TEMPORARY | TEMP } ] TABLE <replaceable>table_name
This optional clause specifies whether the table created by
<command>CREATE TABLE AS</command> should include OIDs. If
neither form of this clause if specified, the value of the
<varname>default_with_oids</varname> configuration parameter is
<xref linkend="guc-default-with-oids"> configuration parameter is
used.
</para>
</listitem>
@ -152,7 +152,7 @@ CREATE [ [ GLOBAL | LOCAL ] { TEMPORARY | TEMP } ] TABLE <replaceable>table_name
the <command>CREATE TABLE AS</command> command allows the user to
explicitely specify whether OIDs should be included. If the
presence of OIDs is not explicitely specified,
the <varname>default_with_oids</varname> configuration variable is
the <xref linkend="guc-default-with-oids"> configuration variable is
used. While this variable currently defaults to true, the default
value may be changed in the future. Therefore, applications that
require OIDs in the table created by <command>CREATE TABLE

View File

@ -1,5 +1,5 @@
<!--
$PostgreSQL: pgsql/doc/src/sgml/ref/create_user.sgml,v 1.32 2003/12/14 00:15:03 neilc Exp $
$PostgreSQL: pgsql/doc/src/sgml/ref/create_user.sgml,v 1.33 2004/03/09 16:57:47 neilc Exp $
PostgreSQL documentation
-->
@ -98,7 +98,7 @@ where <replaceable class="PARAMETER">option</replaceable> can be:
These key words control whether the password is stored
encrypted in the system catalogs. (If neither is specified,
the default behavior is determined by the configuration
parameter <varname>password_encryption</varname>.) If the
parameter <xref linkend="guc-password-encryption">.) If the
presented password string is already in MD5-encrypted format,
then it is stored encrypted as-is, regardless of whether
<literal>ENCRYPTED</> or <literal>UNENCRYPTED</> is specified

View File

@ -1,5 +1,5 @@
<!--
$PostgreSQL: pgsql/doc/src/sgml/ref/explain.sgml,v 1.32 2003/11/29 19:51:38 pgsql Exp $
$PostgreSQL: pgsql/doc/src/sgml/ref/explain.sgml,v 1.33 2004/03/09 16:57:47 neilc Exp $
PostgreSQL documentation
-->
@ -100,8 +100,8 @@ ROLLBACK;
than just a summary. Usually this option is only useful for
debugging <productname>PostgreSQL</productname>. The
<literal>VERBOSE</literal> output is either pretty-printed or
not, depending on the setting of the
<varname>explain_pretty_print</varname> configuration parameter.
not, depending on the setting of the <xref
linkend="guc-explain-pretty-print"> configuration parameter.
</para>
</listitem>
</varlistentry>

View File

@ -1,5 +1,5 @@
<!--
$PostgreSQL: pgsql/doc/src/sgml/ref/postmaster.sgml,v 1.45 2004/02/03 17:34:02 tgl Exp $
$PostgreSQL: pgsql/doc/src/sgml/ref/postmaster.sgml,v 1.46 2004/03/09 16:57:47 neilc Exp $
PostgreSQL documentation
-->
@ -376,7 +376,7 @@ PostgreSQL documentation
<listitem>
<para>
Default value of the <varname>DateStyle</varname> run-time
Default value of the <xref linkend="guc-datestyle"> run-time
parameter. (The use of this environment variable is deprecated.)
</para>
</listitem>
@ -429,10 +429,11 @@ PostgreSQL documentation
<tip>
<para>
You may be able to postpone reconfiguring your kernel by decreasing
<varname>shared_buffers</varname> to reduce the shared memory consumption
of <productname>PostgreSQL</>, and/or by reducing
<varname>max_connections</varname> to reduce the semaphore consumption.
You may be able to postpone reconfiguring your kernel by
decreasing <xref linkend="guc-shared-buffers"> to reduce the
shared memory consumption of <productname>PostgreSQL</>, and/or
by reducing <xref linkend="guc-max-connections"> to reduce the
semaphore consumption.
</para>
</tip>

View File

@ -1,5 +1,5 @@
<!--
$PostgreSQL: pgsql/doc/src/sgml/ref/select.sgml,v 1.75 2004/03/03 22:22:24 neilc Exp $
$PostgreSQL: pgsql/doc/src/sgml/ref/select.sgml,v 1.76 2004/03/09 16:57:47 neilc Exp $
PostgreSQL documentation
-->
@ -190,8 +190,8 @@ where <replaceable class="parameter">from_item</replaceable> can be one of:
tables are to be scanned, but in the current version, this is
the default behavior. (In releases before 7.1,
<literal>ONLY</> was the default behavior.) The default
behavior can be modified by changing the
<varname>sql_interitance</varname> configuration option.
behavior can be modified by changing the <xref
linkend="guc-sql-inheritance"> configuration option.
</para>
</listitem>
</varlistentry>
@ -1023,7 +1023,7 @@ SELECT distributors.* FROM distributors d, distributors distributors;
<command>SELECT</command> statement that also contains an explicit
<literal>FROM</literal> clause. Also, it is possible to disable
the implicit-<literal>FROM</literal> feature by setting the
<varname>add_missing_from</> parameter to false.
<xref linkend="guc-add-missing-from"> parameter to false.
</para>
</refsect2>

View File

@ -1,5 +1,5 @@
<!--
$PostgreSQL: pgsql/doc/src/sgml/ref/select_into.sgml,v 1.27 2003/12/13 23:59:07 neilc Exp $
$PostgreSQL: pgsql/doc/src/sgml/ref/select_into.sgml,v 1.28 2004/03/09 16:57:47 neilc Exp $
PostgreSQL documentation
-->
@ -103,7 +103,7 @@ SELECT [ ALL | DISTINCT [ ON ( <replaceable class="PARAMETER">expression</replac
rapidly incremented. As of <productname>PostgreSQL</> 7.5, the
inclusion of OIDs in the table created by <command>SELECT
INTO</command> is controlled by the
<varname>default_with_oids</varname> configuration variable. This
<xref linkend="guc-default-with-oids"> configuration variable. This
variable currently defaults to true, but will likely default to
false in a future release of <productname>PostgreSQL</>.
</para>

File diff suppressed because it is too large Load Diff

View File

@ -1,4 +1,4 @@
<!-- $PostgreSQL: pgsql/doc/src/sgml/wal.sgml,v 1.27 2004/01/06 17:26:23 neilc Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/wal.sgml,v 1.28 2004/03/09 16:57:47 neilc Exp $ -->
<chapter id="wal">
<title>Write-Ahead Logging (<acronym>WAL</acronym>)</title>
@ -162,10 +162,10 @@
</para>
<para>
The server spawns a special process every so often
to create the next checkpoint. A checkpoint is created every
<varname>checkpoint_segments</varname> log segments, or every
<varname>checkpoint_timeout</varname> seconds, whichever comes first.
The server spawns a special process every so often to create the
next checkpoint. A checkpoint is created every <xref
linkend="guc-checkpoint-segments"> log segments, or every <xref
linkend="guc-checkpoint-timeout"> seconds, whichever comes first.
The default settings are 3 segments and 300 seconds respectively.
It is also possible to force a checkpoint by using the SQL command
<command>CHECKPOINT</command>.
@ -204,11 +204,11 @@
space for the new record, <function>LogInsert</function> will have
to write (move to kernel cache) a few filled <acronym>WAL</acronym>
buffers. This is undesirable because <function>LogInsert</function>
is used on every database low level modification (for example,
row insertion) at a time when an exclusive lock is held on
affected data pages, so the operation needs to be as fast as
possible. What is worse, writing <acronym>WAL</acronym> buffers may
also force the creation of a new log segment, which takes even more
is used on every database low level modification (for example, row
insertion) at a time when an exclusive lock is held on affected
data pages, so the operation needs to be as fast as possible. What
is worse, writing <acronym>WAL</acronym> buffers may also force the
creation of a new log segment, which takes even more
time. Normally, <acronym>WAL</acronym> buffers should be written
and flushed by a <function>LogFlush</function> request, which is
made, for the most part, at transaction commit time to ensure that
@ -217,9 +217,9 @@
not occur often enough to prevent <acronym>WAL</acronym> buffers
being written by <function>LogInsert</function>. On such systems
one should increase the number of <acronym>WAL</acronym> buffers by
modifying the configuration parameter <varname>wal_buffers</varname>.
The default number of <acronym>
WAL</acronym> buffers is 8. Increasing this value will
modifying the configuration parameter <xref
linkend="guc-wal-buffers">. The default number of <acronym>
WAL</acronym> buffers is 8. Increasing this value will
correspondingly increase shared memory usage.
</para>
@ -228,20 +228,20 @@
buffers to disk using the operating system <literal>sync()</> call.
Busy servers may fill checkpoint segment files too quickly,
causing excessive checkpointing. If such forced checkpoints happen
more frequently than <varname>checkpoint_warning</varname> seconds,
more frequently than <xref linkend="guc-checkpoint-warning"> seconds,
a message, will be output to the server logs recommending increasing
<varname>checkpoint_segments</varname>.
</para>
<para>
The <varname>commit_delay</varname> parameter defines for how many
The <xref linkend="guc-commit-delay"> parameter defines for how many
microseconds the server process will sleep after writing a commit
record to the log with <function>LogInsert</function> but before
performing a <function>LogFlush</function>. This delay allows other
server processes to add their commit records to the log so as to have all
of them flushed with a single log sync. No sleep will occur if
<varname>fsync</varname>
is not enabled, nor if fewer than <varname>commit_siblings</varname>
<xref linkend="guc-fsync">
is not enabled, nor if fewer than <xref linkend="guc-commit-siblings">
other sessions are currently in active transactions; this avoids
sleeping when it's unlikely that any other session will commit soon.
Note that on most platforms, the resolution of a sleep request is
@ -252,7 +252,7 @@
</para>
<para>
The <varname>wal_sync_method</varname> parameter determines how
The <xref linkend="guc-wal-sync-method"> 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,
@ -262,11 +262,12 @@
</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.
Enabling the <xref linkend="guc-wal-debug"> configuration parameter
(provided that <productname>PostgreSQL</productname> has been
compiled with support for it) 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>

View File

@ -1,5 +1,5 @@
<!--
$PostgreSQL: pgsql/doc/src/sgml/xfunc.sgml,v 1.79 2003/11/29 19:51:38 pgsql Exp $
$PostgreSQL: pgsql/doc/src/sgml/xfunc.sgml,v 1.80 2004/03/09 16:57:47 neilc Exp $
-->
<sect1 id="xfunc">
@ -738,7 +738,7 @@ CREATE FUNCTION square_root(double precision) RETURNS double precision
<para>
If the name does not contain a directory part, the file is
searched for in the path specified by the configuration variable
<varname>dynamic_library_path</varname>.<indexterm><primary>dynamic_library_path</></>
<xref linkend="guc-dynamic-library-path">.<indexterm><primary>dynamic_library_path</></>
</para>
</listitem>