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:
parent
8567bb2d06
commit
80ec228389
|
@ -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>
|
||||
|
|
|
@ -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>
|
||||
|
||||
|
|
|
@ -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>
|
||||
|
|
|
@ -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</>,
|
||||
|
|
|
@ -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>
|
||||
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -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>
|
||||
|
|
|
@ -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>
|
||||
|
|
|
@ -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>
|
||||
|
|
|
@ -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"
|
||||
|
|
|
@ -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>
|
||||
|
|
|
@ -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</>.)
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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>
|
||||
|
|
|
@ -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>
|
||||
|
||||
|
|
|
@ -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>
|
||||
|
||||
|
|
|
@ -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
|
@ -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>
|
||||
|
||||
|
|
|
@ -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>
|
||||
|
||||
|
|
Loading…
Reference in New Issue