mirror of
https://github.com/postgres/postgres.git
synced 2025-10-30 00:04:49 -04:00
Spellchecking run, final cleanups
This commit is contained in:
Peter Eisentraut
parent
1630571a04
commit
39dfbe5791
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/array.sgml,v 1.45 2005/11/04 02:56:30 tgl Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/array.sgml,v 1.46 2005/11/04 23:13:59 petere Exp $ -->
|
||||
|
||||
<sect1 id="arrays">
|
||||
<title>Arrays</title>
|
||||
@ -59,7 +59,7 @@ CREATE TABLE tictactoe (
|
||||
all considered to be of the same type, regardless of size or number
|
||||
of dimensions. So, declaring number of dimensions or sizes in
|
||||
<command>CREATE TABLE</command> is simply documentation, it does not
|
||||
affect runtime behavior.
|
||||
affect run-time behavior.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/backup.sgml,v 2.74 2005/10/26 20:42:35 tgl Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/backup.sgml,v 2.75 2005/11/04 23:13:59 petere Exp $
|
||||
-->
|
||||
<chapter id="backup">
|
||||
<title>Backup and Restore</title>
|
||||
@ -598,7 +598,7 @@ archive_command = 'test ! -f .../%f && cp %p .../%f'
|
||||
</para>
|
||||
|
||||
<para>
|
||||
In writing your archive command, you should assume that the filenames to
|
||||
In writing your archive command, you should assume that the file names to
|
||||
be archived may be up to 64 characters long and may contain any
|
||||
combination of ASCII letters, digits, and dots. It is not necessary to
|
||||
remember the original full path (<literal>%p</>) but it is necessary to
|
||||
@ -1173,7 +1173,7 @@ restore_command = 'copy /mnt/server/archivedir/%f "%p"' # Windows
|
||||
the total volume of archived logs by turning off page snapshots
|
||||
using the <xref linkend="guc-full-page-writes"> parameter.
|
||||
(Read the notes and warnings in
|
||||
<xref linkend="reliability"> before you do so.)
|
||||
<xref linkend="wal"> before you do so.)
|
||||
Turning off page snapshots does not prevent use of the logs for PITR
|
||||
operations.
|
||||
An area for future development is to compress archived WAL data by
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
<!--
|
||||
Documentation of the system catalogs, directed toward PostgreSQL developers
|
||||
$PostgreSQL: pgsql/doc/src/sgml/catalogs.sgml,v 2.114 2005/09/13 01:51:18 alvherre Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/catalogs.sgml,v 2.115 2005/11/04 23:13:59 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="catalogs">
|
||||
@ -5416,7 +5416,7 @@
|
||||
and <structfield>histogram_bounds</> arrays can be set on a
|
||||
column-by-column basis using the <command>ALTER TABLE SET STATISTICS</>
|
||||
command, or globally by setting the
|
||||
<xref linkend="guc-default-statistics-target"> runtime parameter.
|
||||
<xref linkend="guc-default-statistics-target"> run-time parameter.
|
||||
</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/charset.sgml,v 2.74 2005/10/13 21:43:43 tgl Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/charset.sgml,v 2.75 2005/11/04 23:13:59 petere Exp $ -->
|
||||
|
||||
<chapter id="charset">
|
||||
<title>Localization</>
|
||||
@ -504,7 +504,7 @@ initdb --locale=sv_SE
|
||||
<row>
|
||||
<entry><literal>MULE_INTERNAL</literal></entry>
|
||||
<entry>Mule internal code</entry>
|
||||
<entry>Multi-lingual Emacs</entry>
|
||||
<entry>Multilingual Emacs</entry>
|
||||
<entry>1-4</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/client-auth.sgml,v 1.85 2005/10/24 15:49:54 momjian Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/client-auth.sgml,v 1.86 2005/11/04 23:13:59 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="client-authentication">
|
||||
@ -901,7 +901,7 @@ omicron bryanh guest1
|
||||
default PAM service name is <literal>postgresql</literal>. You can
|
||||
optionally supply your own service name after the <literal>pam</>
|
||||
key word in the file <filename>pg_hba.conf</filename>.
|
||||
PAM is used only to validate username/password pairs.
|
||||
PAM is used only to validate user name/password pairs.
|
||||
Therefore the user must already exist in the database before PAM
|
||||
can be used for authentication. For more information about
|
||||
PAM, please read the <ulink url="http://www.kernel.org/pub/linux/libs/pam/">
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/config.sgml,v 1.34 2005/11/01 23:19:05 neilc Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/config.sgml,v 1.35 2005/11/04 23:13:59 petere Exp $
|
||||
-->
|
||||
<chapter Id="runtime-config">
|
||||
<title>Server Configuration</title>
|
||||
@ -21,7 +21,7 @@ $PostgreSQL: pgsql/doc/src/sgml/config.sgml,v 1.34 2005/11/01 23:19:05 neilc Exp
|
||||
|
||||
<para>
|
||||
All parameter names are case-insensitive. Every parameter takes a
|
||||
value of one of four types: boolean, integer, floating point,
|
||||
value of one of four types: Boolean, integer, floating point,
|
||||
or string. Boolean values may be written as <literal>ON</literal>,
|
||||
<literal>OFF</literal>, <literal>TRUE</literal>,
|
||||
<literal>FALSE</literal>, <literal>YES</literal>,
|
||||
@ -456,9 +456,9 @@ SET ENABLE_SEQSCAN TO OFF;
|
||||
</indexterm>
|
||||
<listitem>
|
||||
<para>
|
||||
On systems that support the TCP_KEEPIDLE socket option, specifies the
|
||||
On systems that support the <symbol>TCP_KEEPIDLE</symbol> socket option, specifies the
|
||||
number of seconds between sending keepalives on an otherwise idle
|
||||
connection. A value of 0 uses the system default. If TCP_KEEPIDLE is
|
||||
connection. A value of 0 uses the system default. If <symbol>TCP_KEEPIDLE</symbol> is
|
||||
not supported, this parameter must be 0. This option is ignored for
|
||||
connections made via a Unix-domain socket.
|
||||
</para>
|
||||
@ -472,9 +472,9 @@ SET ENABLE_SEQSCAN TO OFF;
|
||||
</indexterm>
|
||||
<listitem>
|
||||
<para>
|
||||
On systems that support the TCP_KEEPINTVL socket option, specifies how
|
||||
On systems that support the <symbol>TCP_KEEPINTVL</symbol> socket option, specifies how
|
||||
long, in seconds, to wait for a response to a keepalive before
|
||||
retransmitting. A value of 0 uses the system default. If TCP_KEEPINTVL
|
||||
retransmitting. A value of 0 uses the system default. If <symbol>TCP_KEEPINTVL</symbol>
|
||||
is not supported, this parameter must be 0. This option is ignored
|
||||
for connections made via a Unix-domain socket.
|
||||
</para>
|
||||
@ -488,9 +488,9 @@ SET ENABLE_SEQSCAN TO OFF;
|
||||
</indexterm>
|
||||
<listitem>
|
||||
<para>
|
||||
On systems that support the TCP_KEEPCNT socket option, specifies how
|
||||
On systems that support the <symbol>TCP_KEEPCNT</symbol> socket option, specifies how
|
||||
many keepalives may be lost before the connection is considered dead.
|
||||
A value of 0 uses the system default. If TCP_KEEPCNT is not
|
||||
A value of 0 uses the system default. If <symbol>TCP_KEEPCNT</symbol> is not
|
||||
supported, this parameter must be 0. This option is ignored
|
||||
for connections made via a Unix-domain socket.
|
||||
</para>
|
||||
@ -590,13 +590,13 @@ SET ENABLE_SEQSCAN TO OFF;
|
||||
</indexterm>
|
||||
<listitem>
|
||||
<para>
|
||||
Sets the hostname part of the service principal.
|
||||
Sets the host name part of the service principal.
|
||||
This, combined with <varname>krb_srvname</>, is used to generate
|
||||
the complete service principal, that is
|
||||
<varname>krb_srvname</><literal>/</><varname>krb_server_hostname</><literal>@</>REALM.
|
||||
</para>
|
||||
<para>
|
||||
If not set, the default is the server hostname. See <xref linkend="kerberos-auth">
|
||||
If not set, the default is the server host name. See <xref linkend="kerberos-auth">
|
||||
for details. This parameter can only be set at server start.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -609,7 +609,7 @@ SET ENABLE_SEQSCAN TO OFF;
|
||||
</indexterm>
|
||||
<listitem>
|
||||
<para>
|
||||
Sets whether Kerberos usernames should be treated case-insensitively.
|
||||
Sets whether Kerberos user names should be treated case-insensitively.
|
||||
The default is <literal>off</> (case sensitive). This parameter
|
||||
can only be set at server start.
|
||||
</para>
|
||||
@ -2258,8 +2258,8 @@ SELECT * FROM parent WHERE key = 2400;
|
||||
<varname>log_rotation_age</varname> to <literal>60</literal>, and
|
||||
<varname>log_rotation_size</varname> to <literal>1000000</literal>.
|
||||
Including <literal>%M</> in <varname>log_filename</varname> allows
|
||||
any size-driven rotations that may occur to select a filename
|
||||
different from the hour's initial filename.
|
||||
any size-driven rotations that may occur to select a file name
|
||||
different from the hour's initial file name.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -2663,7 +2663,7 @@ SELECT * FROM parent WHERE key = 2400;
|
||||
</row>
|
||||
<row>
|
||||
<entry><literal>%h</literal></entry>
|
||||
<entry>Remote Hostname or IP address</entry>
|
||||
<entry>Remote host name or IP address</entry>
|
||||
<entry>yes</entry>
|
||||
</row>
|
||||
<row>
|
||||
@ -2794,7 +2794,7 @@ SELECT * FROM parent WHERE key = 2400;
|
||||
</sect1>
|
||||
|
||||
<sect1 id="runtime-config-statistics">
|
||||
<title>Runtime Statistics</title>
|
||||
<title>Run-Time Statistics</title>
|
||||
|
||||
<sect2 id="runtime-config-statistics-monitor">
|
||||
<title>Statistics Monitoring</title>
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/cvs.sgml,v 1.35 2005/10/15 20:15:48 neilc Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/cvs.sgml,v 1.36 2005/11/04 23:13:59 petere Exp $
|
||||
-->
|
||||
|
||||
<appendix id="cvs">
|
||||
@ -64,9 +64,9 @@ $PostgreSQL: pgsql/doc/src/sgml/cvs.sgml,v 1.35 2005/10/15 20:15:48 neilc Exp $
|
||||
<para>
|
||||
Do an initial login to the <productname>CVS</productname> server:
|
||||
|
||||
<programlisting>
|
||||
<programlisting>
|
||||
cvs -d :pserver:anoncvs@anoncvs.postgresql.org:/projects/cvsroot login
|
||||
</programlisting>
|
||||
</programlisting>
|
||||
|
||||
You will be prompted for a password; you can enter anything except
|
||||
an empty string.
|
||||
@ -81,9 +81,9 @@ cvs -d :pserver:anoncvs@anoncvs.postgresql.org:/projects/cvsroot login
|
||||
<step>
|
||||
<para>
|
||||
Fetch the <productname>PostgreSQL</productname> sources:
|
||||
<programlisting>
|
||||
<programlisting>
|
||||
cvs -z3 -d :pserver:anoncvs@anoncvs.postgresql.org:/projects/cvsroot co -P pgsql
|
||||
</programlisting>
|
||||
</programlisting>
|
||||
|
||||
This installs the <productname>PostgreSQL</productname> sources into a
|
||||
subdirectory <filename>pgsql</filename>
|
||||
@ -113,9 +113,9 @@ cvs -z3 -d :pserver:anoncvs@anoncvs.postgresql.org:/projects/cvsroot co -P pgsql
|
||||
Whenever you want to update to the latest <productname>CVS</productname> sources,
|
||||
<command>cd</command> into
|
||||
the <filename>pgsql</filename> subdirectory, and issue
|
||||
<programlisting>
|
||||
$ cvs -z3 update -d -P
|
||||
</programlisting>
|
||||
<programlisting>
|
||||
cvs -z3 update -d -P
|
||||
</programlisting>
|
||||
|
||||
This will fetch only the changes since the last time you updated.
|
||||
You can update in just a couple of minutes, typically, even over
|
||||
@ -128,17 +128,17 @@ $ cvs -z3 update -d -P
|
||||
You can save yourself some typing by making a file <filename>.cvsrc</filename>
|
||||
in your home directory that contains
|
||||
|
||||
<programlisting>
|
||||
<programlisting>
|
||||
cvs -z3
|
||||
update -d -P
|
||||
</programlisting>
|
||||
</programlisting>
|
||||
|
||||
This supplies the <option>-z3</option> option to all cvs commands, and the
|
||||
<option>-d</option> and <option>-P</option> options to cvs update. Then you just have
|
||||
to say
|
||||
<programlisting>
|
||||
$ cvs update
|
||||
</programlisting>
|
||||
<programlisting>
|
||||
cvs update
|
||||
</programlisting>
|
||||
|
||||
to update your files.
|
||||
</para>
|
||||
@ -150,9 +150,9 @@ $ cvs update
|
||||
Some older versions of <productname>CVS</productname> have a bug that
|
||||
causes all checked-out files to be stored world-writable in your
|
||||
directory. If you see that this has happened, you can do something like
|
||||
<programlisting>
|
||||
$ chmod -R go-w pgsql
|
||||
</programlisting>
|
||||
<programlisting>
|
||||
chmod -R go-w pgsql
|
||||
</programlisting>
|
||||
to set the permissions properly.
|
||||
This bug is fixed as of
|
||||
<productname>CVS</productname> version 1.9.28.
|
||||
@ -191,9 +191,9 @@ $ chmod -R go-w pgsql
|
||||
sources that make up release 6_4 of the module `tc' at any time in the
|
||||
future:
|
||||
|
||||
<programlisting>
|
||||
$ cvs checkout -r REL6_4 tc
|
||||
</programlisting>
|
||||
<programlisting>
|
||||
cvs checkout -r REL6_4 tc
|
||||
</programlisting>
|
||||
|
||||
This is useful, for instance, if someone claims that there is a bug in
|
||||
that release, but you cannot find the bug in the current working copy.
|
||||
@ -236,10 +236,10 @@ $ cvs checkout -r REL6_4 tc
|
||||
So, to create the 6.4 release
|
||||
I did the following:
|
||||
|
||||
<programlisting>
|
||||
$ cd pgsql
|
||||
$ cvs tag -b REL6_4
|
||||
</programlisting>
|
||||
<programlisting>
|
||||
cd pgsql
|
||||
cvs tag -b REL6_4
|
||||
</programlisting>
|
||||
|
||||
which will create the tag and the branch for the RELEASE tree.
|
||||
</para>
|
||||
@ -250,12 +250,12 @@ $ cvs tag -b REL6_4
|
||||
First, create two subdirectories, RELEASE and CURRENT, so that you don't
|
||||
mix up the two. Then do:
|
||||
|
||||
<programlisting>
|
||||
<programlisting>
|
||||
cd RELEASE
|
||||
cvs checkout -P -r REL6_4 pgsql
|
||||
cd ../CURRENT
|
||||
cvs checkout -P pgsql
|
||||
</programlisting>
|
||||
</programlisting>
|
||||
|
||||
which results in two directory trees, <filename>RELEASE/pgsql</filename> and
|
||||
<filename>CURRENT/pgsql</filename>. From that point on,
|
||||
@ -273,16 +273,16 @@ cvs checkout -P pgsql
|
||||
<para>
|
||||
After you've done the initial checkout on a branch
|
||||
|
||||
<programlisting>
|
||||
$ cvs checkout -r REL6_4
|
||||
</programlisting>
|
||||
<programlisting>
|
||||
cvs checkout -r REL6_4
|
||||
</programlisting>
|
||||
|
||||
anything you do within that directory structure is restricted to that
|
||||
branch. If you apply a patch to that directory structure and do a
|
||||
|
||||
<programlisting>
|
||||
<programlisting>
|
||||
cvs commit
|
||||
</programlisting>
|
||||
</programlisting>
|
||||
|
||||
while inside of it, the patch is applied to the branch and
|
||||
<emphasis>only</emphasis> the branch.
|
||||
@ -333,9 +333,9 @@ cvs commit
|
||||
<filename>/opt/postgres/cvs/</filename>. If you intend to keep your
|
||||
repository in <filename>/home/cvs/</filename>, then put
|
||||
|
||||
<programlisting>
|
||||
<programlisting>
|
||||
setenv CVSROOT /home/cvs
|
||||
</programlisting>
|
||||
</programlisting>
|
||||
|
||||
in your <filename>.cshrc</filename> file, or a similar line in
|
||||
your <filename>.bashrc</filename> or
|
||||
@ -347,18 +347,18 @@ setenv CVSROOT /home/cvs
|
||||
Once <envar>CVSROOT</envar> is set, then this can be done with a
|
||||
single command:
|
||||
|
||||
<programlisting>
|
||||
$ cvs init
|
||||
</programlisting>
|
||||
<programlisting>
|
||||
cvs init
|
||||
</programlisting>
|
||||
|
||||
after which you should see at least a directory named
|
||||
<filename>CVSROOT</filename> when listing the
|
||||
<envar>CVSROOT</envar> directory:
|
||||
|
||||
<programlisting>
|
||||
<programlisting>
|
||||
$ ls $CVSROOT
|
||||
CVSROOT/
|
||||
</programlisting>
|
||||
</programlisting>
|
||||
</para>
|
||||
</sect2>
|
||||
|
||||
@ -370,16 +370,16 @@ CVSROOT/
|
||||
<application>cvsup</application> is in your path; on most systems
|
||||
you can do this by typing
|
||||
|
||||
<programlisting>
|
||||
<programlisting>
|
||||
which cvsup
|
||||
</programlisting>
|
||||
</programlisting>
|
||||
|
||||
Then, simply run
|
||||
<application>cvsup</application> using:
|
||||
|
||||
<programlisting>
|
||||
$ cvsup -L 2 <replaceable class="parameter">postgres.cvsup</replaceable>
|
||||
</programlisting>
|
||||
<programlisting>
|
||||
cvsup -L 2 <replaceable class="parameter">postgres.cvsup</replaceable>
|
||||
</programlisting>
|
||||
|
||||
where <option>-L 2</option> enables some status messages so you
|
||||
can monitor the progress of the update,
|
||||
@ -393,7 +393,7 @@ $ cvsup -L 2 <replaceable class="parameter">postgres.cvsup</replaceable>
|
||||
modified for a specific installation, and which maintains a full
|
||||
local <productname>CVS</productname> repository:
|
||||
|
||||
<programlisting>
|
||||
<programlisting>
|
||||
# This file represents the standard CVSup distribution file
|
||||
# for the <productname>PostgreSQL</> ORDBMS project
|
||||
# Modified by lockhart@fourpalms.org 1997-08-28
|
||||
@ -426,8 +426,7 @@ pgsql
|
||||
# pgsql-doc
|
||||
# pgsql-perl5
|
||||
# pgsql-src
|
||||
|
||||
</programlisting>
|
||||
</programlisting>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -454,7 +453,7 @@ CVSROOT/loginfo*
|
||||
ftp site</ulink>
|
||||
which will fetch the current snapshot only:
|
||||
|
||||
<programlisting>
|
||||
<programlisting>
|
||||
# This file represents the standard CVSup distribution file
|
||||
# for the <productname>PostgreSQL</> ORDBMS project
|
||||
#
|
||||
@ -478,8 +477,7 @@ pgsql
|
||||
# pgsql-doc
|
||||
# pgsql-perl5
|
||||
# pgsql-src
|
||||
|
||||
</programlisting>
|
||||
</programlisting>
|
||||
</para>
|
||||
</sect2>
|
||||
|
||||
@ -563,11 +561,11 @@ pgsql
|
||||
If the binary is in the top level of the tar file, then simply
|
||||
unpack the tar file into your target directory:
|
||||
|
||||
<programlisting>
|
||||
$ cd /usr/local/bin
|
||||
$ tar zxvf /usr/local/src/cvsup-16.0-linux-i386.tar.gz
|
||||
$ mv cvsup.1 ../doc/man/man1/
|
||||
</programlisting>
|
||||
<programlisting>
|
||||
cd /usr/local/bin
|
||||
tar zxvf /usr/local/src/cvsup-16.0-linux-i386.tar.gz
|
||||
mv cvsup.1 ../doc/man/man1/
|
||||
</programlisting>
|
||||
</para>
|
||||
</step>
|
||||
|
||||
@ -585,13 +583,13 @@ $ mv cvsup.1 ../doc/man/man1/
|
||||
<para>
|
||||
Ensure that the new binaries are in your path.
|
||||
|
||||
<programlisting>
|
||||
<programlisting>
|
||||
$ rehash
|
||||
$ which cvsup
|
||||
$ set path=(<replaceable>path to cvsup</replaceable> $path)
|
||||
$ which cvsup
|
||||
/usr/local/bin/cvsup
|
||||
</programlisting>
|
||||
</programlisting>
|
||||
</para>
|
||||
</step>
|
||||
</procedure>
|
||||
@ -651,9 +649,9 @@ $ which cvsup
|
||||
<para>
|
||||
Install the Modula-3 rpms:
|
||||
|
||||
<programlisting>
|
||||
<programlisting>
|
||||
# rpm -Uvh pm3*.rpm
|
||||
</programlisting>
|
||||
</programlisting>
|
||||
</para>
|
||||
</step>
|
||||
</substeps>
|
||||
@ -663,10 +661,10 @@ $ which cvsup
|
||||
<para>
|
||||
Unpack the cvsup distribution:
|
||||
|
||||
<programlisting>
|
||||
<programlisting>
|
||||
# cd /usr/local/src
|
||||
# tar zxf cvsup-16.0.tar.gz
|
||||
</programlisting>
|
||||
</programlisting>
|
||||
</para>
|
||||
</step>
|
||||
|
||||
@ -675,16 +673,16 @@ $ which cvsup
|
||||
Build the cvsup distribution, suppressing the GUI interface
|
||||
feature to avoid requiring X11 libraries:
|
||||
|
||||
<programlisting>
|
||||
<programlisting>
|
||||
# make M3FLAGS="-DNOGUI"
|
||||
</programlisting>
|
||||
</programlisting>
|
||||
|
||||
and if you want to build a static binary to move to systems
|
||||
that may not have Modula-3 installed, try:
|
||||
|
||||
<programlisting>
|
||||
<programlisting>
|
||||
# make M3FLAGS="-DNOGUI -DSTATIC"
|
||||
</programlisting>
|
||||
</programlisting>
|
||||
</para>
|
||||
</step>
|
||||
|
||||
@ -692,29 +690,12 @@ $ which cvsup
|
||||
<para>
|
||||
Install the built binary:
|
||||
|
||||
<programlisting>
|
||||
<programlisting>
|
||||
# make M3FLAGS="-DNOGUI -DSTATIC" install
|
||||
</programlisting>
|
||||
</programlisting>
|
||||
</para>
|
||||
</step>
|
||||
</procedure>
|
||||
</sect2>
|
||||
</sect1>
|
||||
</appendix>
|
||||
|
||||
<!-- Keep this comment at the end of the file
|
||||
Local variables:
|
||||
mode:sgml
|
||||
sgml-omittag:nil
|
||||
sgml-shorttag:t
|
||||
sgml-minimize-attributes:nil
|
||||
sgml-always-quote-attributes:t
|
||||
sgml-indent-step:1
|
||||
sgml-indent-data:t
|
||||
sgml-parent-document:nil
|
||||
sgml-default-dtd-file:"./reference.ced"
|
||||
sgml-exposed-tags:nil
|
||||
sgml-local-catalogs:("/usr/lib/sgml/catalog")
|
||||
sgml-local-ecat-files:nil
|
||||
End:
|
||||
-->
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/ddl.sgml,v 1.48 2005/11/04 02:56:30 tgl Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/ddl.sgml,v 1.49 2005/11/04 23:13:59 petere Exp $ -->
|
||||
|
||||
<chapter id="ddl">
|
||||
<title>Data Definition</title>
|
||||
@ -202,7 +202,7 @@ CREATE TABLE products (
|
||||
The default value may be an expression, which will be
|
||||
evaluated whenever the default value is inserted
|
||||
(<emphasis>not</emphasis> when the table is created). A common example
|
||||
is that a timestamp column may have a default of <literal>now()</>,
|
||||
is that a <type>timestamp</type> column may have a default of <literal>now()</>,
|
||||
so that it gets set to the time of row insertion. Another common
|
||||
example is generating a <quote>serial number</> for each row.
|
||||
In <productname>PostgreSQL</productname> this is typically done by
|
||||
@ -1157,7 +1157,7 @@ SELECT name, altitude
|
||||
</note>
|
||||
|
||||
<para>
|
||||
Inheritance does not automatically propogate data from
|
||||
Inheritance does not automatically propagate data from
|
||||
<command>INSERT</command> or <command>COPY</command> commands to
|
||||
other tables in the inheritance hierarchy. In our example, the
|
||||
following <command>INSERT</command> statement will fail:
|
||||
@ -1221,12 +1221,12 @@ WHERE c.altitude > 500 and c.tableoid = p.oid;
|
||||
<para>
|
||||
As shown above, a child table may locally define columns as well as
|
||||
inheriting them from their parents. However, a locally defined
|
||||
column cannot override the datatype of an inherited column of the
|
||||
column cannot override the data type of an inherited column of the
|
||||
same name. A table can inherit from a table that has itself
|
||||
inherited from other tables. A table can also inherit from more
|
||||
than one parent table, in which case it inherits the union of the
|
||||
columns defined by the parent tables. Inherited columns with
|
||||
duplicate names and datatypes will be merged so that only a single
|
||||
duplicate names and data types will be merged so that only a single
|
||||
column is stored.
|
||||
</para>
|
||||
|
||||
@ -1498,7 +1498,7 @@ CHECK ( county IN ( 'Oxfordshire','Buckinghamshire','Warwickshire' ))
|
||||
CHECK ( outletID BETWEEN 1 AND 99 )
|
||||
</programlisting>
|
||||
|
||||
These can be linked together with the boolean operators
|
||||
These can be linked together with the Boolean operators
|
||||
<literal>AND</literal> and <literal>OR</literal> to form
|
||||
complex constraints. Note that there is no difference in
|
||||
syntax between range and list partitioning; those terms are
|
||||
@ -1722,10 +1722,10 @@ DO INSTEAD
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
For some datatypes you must explicitly coerce the constant
|
||||
values into the datatype of the column. The following constraint
|
||||
For some data types you must explicitly coerce the constant
|
||||
values into the data type of the column. The following constraint
|
||||
will work if <varname>x</varname> is an <type>integer</type>
|
||||
datatype, but not if <varname>x</varname> is a
|
||||
data type, but not if <varname>x</varname> is a
|
||||
<type>bigint</type>:
|
||||
<programlisting>
|
||||
CHECK ( x = 1 )
|
||||
@ -1734,9 +1734,9 @@ CHECK ( x = 1 )
|
||||
<programlisting>
|
||||
CHECK ( x = 1::bigint )
|
||||
</programlisting>
|
||||
The problem is not limited to the <type>bigint</type> datatype
|
||||
— it can occur whenever the default datatype of the
|
||||
constant does not match the datatype of the column to which it
|
||||
The problem is not limited to the <type>bigint</type> data type
|
||||
— it can occur whenever the default data type of the
|
||||
constant does not match the data type of the column to which it
|
||||
is being compared.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -1849,7 +1849,7 @@ ANALYZE measurement;
|
||||
<listitem>
|
||||
<para>
|
||||
Constraint exclusion only works when the query directly matches
|
||||
a constant. A constant bound to a parameterised query will not
|
||||
a constant. A constant bound to a parameterized query will not
|
||||
work in the same way since the plan is fixed and would need to
|
||||
vary with each execution. Also, stable constants such as
|
||||
<literal>CURRENT_DATE</literal> may not be used, since these are
|
||||
@ -1860,8 +1860,8 @@ ANALYZE measurement;
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
UPDATEs and DELETEs against the master table do not perform
|
||||
constraint exclusion.
|
||||
<command>UPDATE</command> and <command>DELETE</command> commands
|
||||
against the master table do not perform constraint exclusion.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ecpg.sgml,v 1.70 2005/11/04 02:56:30 tgl Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ecpg.sgml,v 1.71 2005/11/04 23:13:59 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="ecpg">
|
||||
@ -1609,11 +1609,11 @@ ECPG = ecpg
|
||||
</para>
|
||||
<note>
|
||||
<para>
|
||||
On Win32, if the <application>ecpg</> libraries and an application are
|
||||
On Windows, if the <application>ecpg</> libraries and an application are
|
||||
compiled with different flags, this function call will crash the
|
||||
application because the internal representation of the
|
||||
<literal>FILE</> pointers differ. Specifically,
|
||||
multi-threaded/single-threaded, release/debug, and static/dynamic
|
||||
multithreaded/single-threaded, release/debug, and static/dynamic
|
||||
flags should be the same for the library and all applications using
|
||||
that library.
|
||||
</para>
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/func.sgml,v 1.290 2005/11/04 02:56:30 tgl Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/func.sgml,v 1.291 2005/11/04 23:13:59 petere Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -3430,7 +3430,7 @@ regexp_replace('foobarbaz', 'b(..)', 'X\\1Y', 'g')
|
||||
|
||||
<note>
|
||||
<para>
|
||||
<productname>PostgreSQL</> currently has no multi-character collating
|
||||
<productname>PostgreSQL</> currently has no multicharacter collating
|
||||
elements. This information describes possible future behavior.
|
||||
</para>
|
||||
</note>
|
||||
@ -3820,7 +3820,7 @@ regexp_replace('foobarbaz', 'b(..)', 'X\\1Y', 'g')
|
||||
A leading zero always indicates an octal escape.
|
||||
A single non-zero digit, not followed by another digit,
|
||||
is always taken as a back reference.
|
||||
A multi-digit sequence not starting with a zero is taken as a back
|
||||
A multidigit sequence not starting with a zero is taken as a back
|
||||
reference if it comes after a suitable subexpression
|
||||
(i.e. the number is in the legal range for a back reference),
|
||||
and otherwise is taken as octal.
|
||||
@ -3970,7 +3970,7 @@ regexp_replace('foobarbaz', 'b(..)', 'X\\1Y', 'g')
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
white space and comments cannot appear within multi-character symbols,
|
||||
white space and comments cannot appear within multicharacter symbols,
|
||||
such as <literal>(?:</>
|
||||
</para>
|
||||
</listitem>
|
||||
@ -3986,7 +3986,7 @@ regexp_replace('foobarbaz', 'b(..)', 'X\\1Y', 'g')
|
||||
(where <replaceable>ttt</> is any text not containing a <literal>)</>)
|
||||
is a comment, completely ignored.
|
||||
Again, this is not allowed between the characters of
|
||||
multi-character symbols, like <literal>(?:</>.
|
||||
multicharacter symbols, like <literal>(?:</>.
|
||||
Such comments are more a historical artifact than a useful facility,
|
||||
and their use is deprecated; use the expanded syntax instead.
|
||||
</para>
|
||||
@ -5954,7 +5954,7 @@ SELECT date_trunc('year', TIMESTAMP '2001-02-16 20:38:40');
|
||||
<literal><type>timestamp without time zone</type> AT TIME ZONE <replaceable>zone</></literal>
|
||||
</entry>
|
||||
<entry><type>timestamp with time zone</type></entry>
|
||||
<entry>Treat given timestamp <emphasis>without time zone</> as located in the specified time zone</entry>
|
||||
<entry>Treat given time stamp <emphasis>without time zone</> as located in the specified time zone</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
@ -5962,7 +5962,7 @@ SELECT date_trunc('year', TIMESTAMP '2001-02-16 20:38:40');
|
||||
<literal><type>timestamp with time zone</type> AT TIME ZONE <replaceable>zone</></literal>
|
||||
</entry>
|
||||
<entry><type>timestamp without time zone</type></entry>
|
||||
<entry>Convert given timestamp <emphasis>with time zone</> to the new time zone</entry>
|
||||
<entry>Convert given time stamp <emphasis>with time zone</> to the new time zone</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
@ -6568,7 +6568,7 @@ SELECT TIMESTAMP 'now'; -- incorrect for use with DEFAULT
|
||||
<row>
|
||||
<entry><literal><function>point</function>(<type>lseg</type>)</literal></entry>
|
||||
<entry><type>point</type></entry>
|
||||
<entry>center of lseg</entry>
|
||||
<entry>center of line segment</entry>
|
||||
<entry><literal>point(lseg '((-1,0),(1,0))')</literal></entry>
|
||||
</row>
|
||||
<row>
|
||||
@ -6929,7 +6929,7 @@ SELECT TIMESTAMP 'now'; -- incorrect for use with DEFAULT
|
||||
The sequence to be operated on by a sequence-function call is specified by
|
||||
a <type>regclass</> argument, which is just the OID of the sequence in the
|
||||
<structname>pg_class</> system catalog. You do not have to look up the
|
||||
OID by hand, however, since the <type>regclass</> datatype's input
|
||||
OID by hand, however, since the <type>regclass</> data type's input
|
||||
converter will do the work for you. Just write the sequence name enclosed
|
||||
in single quotes, so that it looks like a literal constant. To
|
||||
achieve some compatibility with the handling of ordinary
|
||||
@ -6955,7 +6955,7 @@ nextval('foo') <lineannotation>searches search path for <literal>fo
|
||||
Before <productname>PostgreSQL</productname> 8.1, the arguments of the
|
||||
sequence functions were of type <type>text</>, not <type>regclass</>, and
|
||||
the above-described conversion from a text string to an OID value would
|
||||
happen at runtime during each call. For backwards compatibility, this
|
||||
happen at run time during each call. For backwards compatibility, this
|
||||
facility still exists, but internally it is now handled as an implicit
|
||||
coercion from <type>text</> to <type>regclass</> before the function is
|
||||
invoked.
|
||||
@ -6969,7 +6969,7 @@ nextval('foo') <lineannotation>searches search path for <literal>fo
|
||||
etc. This <quote>early binding</> behavior is usually desirable for
|
||||
sequence references in column defaults and views. But sometimes you will
|
||||
want <quote>late binding</> where the sequence reference is resolved
|
||||
at runtime. To get late-binding behavior, force the constant to be
|
||||
at run time. To get late-binding behavior, force the constant to be
|
||||
stored as a <type>text</> constant instead of <type>regclass</>:
|
||||
<programlisting>
|
||||
nextval('foo'::text) <lineannotation><literal>foo</literal> is looked up at runtime</>
|
||||
@ -9444,7 +9444,7 @@ SELECT set_config('log_statement_stats', 'off', false);
|
||||
<literal><function>pg_rotate_logfile</function>()</literal>
|
||||
</entry>
|
||||
<entry><type>boolean</type></entry>
|
||||
<entry>Rotate server's logfile</entry>
|
||||
<entry>Rotate server's log file</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
@ -9472,10 +9472,10 @@ SELECT set_config('log_statement_stats', 'off', false);
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<function>pg_rotate_logfile</> signals the logfile manager to switch
|
||||
<function>pg_rotate_logfile</> signals the log-file manager to switch
|
||||
to a new output file immediately. This works only when
|
||||
<varname>redirect_stderr</> is used for logging, since otherwise there
|
||||
is no logfile manager subprocess.
|
||||
is no log-file manager subprocess.
|
||||
</para>
|
||||
|
||||
<indexterm zone="functions-admin">
|
||||
@ -9757,9 +9757,9 @@ SELECT set_config('log_statement_stats', 'off', false);
|
||||
</indexterm>
|
||||
<para>
|
||||
<function>pg_stat_file</> returns a record containing the file
|
||||
size, last accessed timestamp, last modified timestamp,
|
||||
last file status change timestamp (Unix platforms only),
|
||||
file creation timestamp (Win32 only), and a boolean indicating
|
||||
size, last accessed time stamp, last modified time stamp,
|
||||
last file status change time stamp (Unix platforms only),
|
||||
file creation timestamp (Windows only), and a <type>boolean</type> indicating
|
||||
if it is a directory. Typical usages include:
|
||||
<programlisting>
|
||||
SELECT * FROM pg_stat_file('filename');
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/gist.sgml,v 1.23 2005/10/21 13:59:05 tgl Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/gist.sgml,v 1.24 2005/11/04 23:14:00 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="GiST">
|
||||
@ -52,7 +52,7 @@ $PostgreSQL: pgsql/doc/src/sgml/gist.sgml,v 1.23 2005/10/21 13:59:05 tgl Exp $
|
||||
difficult work. It was necessary to understand the inner workings of the
|
||||
database, such as the lock manager and Write-Ahead Log. The
|
||||
<acronym>GiST</acronym> interface has a high level of abstraction,
|
||||
requiring the access method implementor to only implement the semantics of
|
||||
requiring the access method implementer to only implement the semantics of
|
||||
the data type being accessed. The <acronym>GiST</acronym> layer itself
|
||||
takes care of concurrency, logging and searching the tree structure.
|
||||
</para>
|
||||
@ -187,7 +187,7 @@ $PostgreSQL: pgsql/doc/src/sgml/gist.sgml,v 1.23 2005/10/21 13:59:05 tgl Exp $
|
||||
The <productname>PostgreSQL</productname> source distribution includes
|
||||
several examples of index methods implemented using
|
||||
<acronym>GiST</acronym>. The core system currently provides R-Tree
|
||||
equivalent functionality for some of the built-in geometric datatypes
|
||||
equivalent functionality for some of the built-in geometric data types
|
||||
(see <filename>src/backend/access/gist/gistproc.c</>). The following
|
||||
<filename>contrib</> modules also contain <acronym>GiST</acronym>
|
||||
operator classes:
|
||||
@ -197,7 +197,7 @@ $PostgreSQL: pgsql/doc/src/sgml/gist.sgml,v 1.23 2005/10/21 13:59:05 tgl Exp $
|
||||
<varlistentry>
|
||||
<term>btree_gist</term>
|
||||
<listitem>
|
||||
<para>B-Tree equivalent functionality for several datatypes</para>
|
||||
<para>B-Tree equivalent functionality for several data types</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/indexam.sgml,v 2.6 2005/06/13 23:14:47 tgl Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/indexam.sgml,v 2.7 2005/11/04 23:14:00 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="indexam">
|
||||
@ -56,7 +56,7 @@ $PostgreSQL: pgsql/doc/src/sgml/indexam.sgml,v 2.6 2005/06/13 23:14:47 tgl Exp $
|
||||
functions supplied by the access method. The APIs for these functions
|
||||
are defined later in this chapter. In addition, the
|
||||
<structname>pg_am</structname> row specifies a few fixed properties of
|
||||
the access method, such as whether it can support multi-column indexes.
|
||||
the access method, such as whether it can support multicolumn indexes.
|
||||
There is not currently any special support
|
||||
for creating or deleting <structname>pg_am</structname> entries;
|
||||
anyone able to write a new access method is expected to be competent
|
||||
@ -99,7 +99,7 @@ $PostgreSQL: pgsql/doc/src/sgml/indexam.sgml,v 2.6 2005/06/13 23:14:47 tgl Exp $
|
||||
are discussed in <xref linkend="index-unique-checks">, and those of
|
||||
<structfield>amconcurrent</structfield> in <xref linkend="index-locking">.
|
||||
The <structfield>amcanmulticol</structfield> flag asserts that the
|
||||
access method supports multi-column indexes, while
|
||||
access method supports multicolumn indexes, while
|
||||
<structfield>amoptionalkey</structfield> asserts that it allows scans
|
||||
where no indexable restriction clause is given for the first index column.
|
||||
When <structfield>amcanmulticol</structfield> is false,
|
||||
@ -113,7 +113,7 @@ $PostgreSQL: pgsql/doc/src/sgml/indexam.sgml,v 2.6 2005/06/13 23:14:47 tgl Exp $
|
||||
<structfield>amindexnulls</structfield> asserts that index entries are
|
||||
created for NULL key values. Since most indexable operators are
|
||||
strict and hence cannot return TRUE for NULL inputs,
|
||||
it is at first sight attractive to not store index entries for NULLs:
|
||||
it is at first sight attractive to not store index entries for null values:
|
||||
they could never be returned by an index scan anyway. However, this
|
||||
argument fails when an index scan has no restriction clause for a given
|
||||
index column. In practice this means that
|
||||
@ -242,7 +242,7 @@ ambeginscan (Relation indexRelation,
|
||||
<emphasis>must</> create this struct by calling
|
||||
<function>RelationGetIndexScan()</>. In most cases
|
||||
<function>ambeginscan</> itself does little beyond making that call;
|
||||
the interesting parts of indexscan startup are in <function>amrescan</>.
|
||||
the interesting parts of index-scan startup are in <function>amrescan</>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -291,11 +291,11 @@ amrescan (IndexScanDesc scan,
|
||||
Restart the given scan, possibly with new scan keys (to continue using
|
||||
the old keys, NULL is passed for <literal>key</>). Note that it is not
|
||||
possible for the number of keys to be changed. In practice the restart
|
||||
feature is used when a new outer tuple is selected by a nestloop join
|
||||
feature is used when a new outer tuple is selected by a nested-loop join
|
||||
and so a new key comparison value is needed, but the scan key structure
|
||||
remains the same. This function is also called by
|
||||
<function>RelationGetIndexScan()</>, so it is used for initial setup
|
||||
of an indexscan as well as rescanning.
|
||||
of an index scan as well as rescanning.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -377,7 +377,7 @@ amcostestimate (PlannerInfo *root,
|
||||
The operator class may indicate that the index is <firstterm>lossy</> for a
|
||||
particular operator; this implies that the index scan will return all the
|
||||
entries that pass the scan key, plus possibly additional entries that do
|
||||
not. The core system's indexscan machinery will then apply that operator
|
||||
not. The core system's index-scan machinery will then apply that operator
|
||||
again to the heap tuple to verify whether or not it really should be
|
||||
selected. For non-lossy operators, the index scan must return exactly the
|
||||
set of matching entries, as there is no recheck.
|
||||
@ -524,7 +524,7 @@ amcostestimate (PlannerInfo *root,
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
For concurrent index types, an indexscan must maintain a pin
|
||||
For concurrent index types, an index scan must maintain a pin
|
||||
on the index page holding the item last returned by
|
||||
<function>amgettuple</>, and <function>ambulkdelete</> cannot delete
|
||||
entries from pages that are pinned by other backends. The need
|
||||
@ -553,7 +553,7 @@ amcostestimate (PlannerInfo *root,
|
||||
may still be <quote>in flight</> from the index entry to the matching
|
||||
heap entry. Making <function>ambulkdelete</> block on such a pin ensures
|
||||
that <command>VACUUM</> cannot delete the heap entry before the reader
|
||||
is done with it. This solution costs little in runtime, and adds blocking
|
||||
is done with it. This solution costs little in run time, and adds blocking
|
||||
overhead only in the rare cases where there actually is a conflict.
|
||||
</para>
|
||||
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/indices.sgml,v 1.53 2005/10/21 01:41:28 tgl Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/indices.sgml,v 1.54 2005/11/04 23:14:00 petere Exp $ -->
|
||||
|
||||
<chapter id="indexes">
|
||||
<title id="indexes-title">Indexes</title>
|
||||
@ -235,7 +235,7 @@ CREATE INDEX <replaceable>name</replaceable> ON <replaceable>table</replaceable>
|
||||
Similarly, R-tree indexes do not seem to have any performance
|
||||
advantages compared to the equivalent operations of GiST indexes.
|
||||
Like hash indexes, they are not WAL-logged and may need
|
||||
<command>REINDEX</>ing after a database crash.
|
||||
reindexing after a database crash.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -389,7 +389,7 @@ CREATE INDEX test2_mm_idx ON test2 (major, minor);
|
||||
<para>
|
||||
In all but the simplest applications, there are various combinations of
|
||||
indexes that may be useful, and the database developer must make
|
||||
tradeoffs to decide which indexes to provide. Sometimes multicolumn
|
||||
trade-offs to decide which indexes to provide. Sometimes multicolumn
|
||||
indexes are best, but sometimes it's better to create separate indexes
|
||||
and rely on the index-combination feature. For example, if your
|
||||
workload includes a mix of queries that sometimes involve only column
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/libpq.sgml,v 1.198 2005/10/27 13:53:41 momjian Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/libpq.sgml,v 1.199 2005/11/04 23:14:00 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="libpq">
|
||||
@ -3539,10 +3539,10 @@ void PQtrace(PGconn *conn, FILE *stream);
|
||||
</para>
|
||||
<note>
|
||||
<para>
|
||||
On Win32, if the <application>libpq</> library and an application are
|
||||
On Windows, if the <application>libpq</> library and an application are
|
||||
compiled with different flags, this function call will crash the
|
||||
application because the internal representation of the <literal>FILE</>
|
||||
pointers differ. Specifically, multi-threaded/single-threaded,
|
||||
pointers differ. Specifically, multithreaded/single-threaded,
|
||||
release/debug, and static/dynamic flags should be the same for the
|
||||
library and all applications using that library.
|
||||
</para>
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/maintenance.sgml,v 1.50 2005/11/01 21:09:49 tgl Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/maintenance.sgml,v 1.51 2005/11/04 23:14:00 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="maintenance">
|
||||
@ -593,7 +593,7 @@ analyze threshold = analyze base threshold + analyze scale factor * number of tu
|
||||
<para>
|
||||
In <productname>PostgreSQL</> releases before 7.4, periodic reindexing
|
||||
was frequently necessary to avoid <quote>index bloat</>, due to lack of
|
||||
internal space reclamation in btree indexes. Any situation in which the
|
||||
internal space reclamation in B-tree indexes. Any situation in which the
|
||||
range of index keys changed over time — for example, an index on
|
||||
timestamps in a table where old entries are eventually deleted —
|
||||
would result in bloat, because index pages for no-longer-needed portions
|
||||
@ -613,16 +613,16 @@ analyze threshold = analyze base threshold + analyze scale factor * number of tu
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The potential for bloat in non-btree indexes has not been well
|
||||
The potential for bloat in non-B-tree indexes has not been well
|
||||
characterized. It is a good idea to keep an eye on the index's physical
|
||||
size when using any non-btree index type.
|
||||
size when using any non-B-tree index type.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Also, for btree indexes a freshly-constructed index is somewhat faster to
|
||||
Also, for B-tree indexes a freshly-constructed index is somewhat faster to
|
||||
access than one that has been updated many times, because logically
|
||||
adjacent pages are usually also physically adjacent in a newly built index.
|
||||
(This consideration does not currently apply to non-btree indexes.) It
|
||||
(This consideration does not currently apply to non-B-tree indexes.) It
|
||||
might be worthwhile to reindex periodically just to improve access speed.
|
||||
</para>
|
||||
</sect1>
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/nls.sgml,v 1.12 2005/04/09 03:52:43 momjian Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/nls.sgml,v 1.13 2005/11/04 23:14:00 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="nls">
|
||||
@ -458,7 +458,7 @@ printf("Files were %s.\n", flag ? "copied" : "removed");
|
||||
fragment, the fragments may not translate well separately. It's
|
||||
better to duplicate a little code so that each message to be
|
||||
translated is a coherent whole. Only numbers, file names, and
|
||||
such-like run-time variables should be inserted at runtime into
|
||||
such-like run-time variables should be inserted at run time into
|
||||
a message text.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/perform.sgml,v 1.53 2005/09/02 03:19:53 tgl Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/perform.sgml,v 1.54 2005/11/04 23:14:00 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="performance-tips">
|
||||
@ -826,7 +826,7 @@ SELECT * FROM x, y, a, b, c WHERE something AND somethingelse;
|
||||
Just as with indexes, a foreign key constraint can be checked
|
||||
<quote>in bulk</> more efficiently than row-by-row. So it may be
|
||||
useful to drop foreign key constraints, load data, and re-create
|
||||
the constraints. Again, there is a tradeoff between data load
|
||||
the constraints. Again, there is a trade-off between data load
|
||||
speed and loss of error checking while the constraint is missing.
|
||||
</para>
|
||||
</sect2>
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/planstats.sgml,v 1.4 2005/10/15 20:12:32 neilc Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/planstats.sgml,v 1.5 2005/11/04 23:14:00 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="planner-stats-details">
|
||||
@ -327,7 +327,7 @@ selectivity = (1 - null_frac1) * (1 - null_frac2) * min(1/num_distinct1, 1/num_d
|
||||
This is, subtract the null fraction from one for each of the relations,
|
||||
and divide by the maximum of the two distinct values. The number of rows
|
||||
that the join is likely to emit is calculated as the cardinality of
|
||||
cartesian product of the two nodes in the nested-loop, multiplied by the
|
||||
Cartesian product of the two nodes in the nested-loop, multiplied by the
|
||||
selectivity:
|
||||
|
||||
<programlisting>
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/plperl.sgml,v 2.48 2005/10/24 15:39:50 adunstan Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/plperl.sgml,v 2.49 2005/11/04 23:14:00 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="plperl">
|
||||
@ -313,7 +313,7 @@ BEGIN { strict->import(); }
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>spi_exec_query</literal> executes an SQL command and
|
||||
returns the entire rowset as a reference to an array of hash
|
||||
returns the entire row set as a reference to an array of hash
|
||||
references. <emphasis>You should only use this command when you know
|
||||
that the result set will be relatively small.</emphasis> Here is an
|
||||
example of a query (<command>SELECT</command> command) with the
|
||||
@ -384,7 +384,7 @@ SELECT * FROM test_munge();
|
||||
</para>
|
||||
<para>
|
||||
<literal>spi_query</literal> and <literal>spi_fetchrow</literal>
|
||||
work together as a pair for rowsets which may be large, or for cases
|
||||
work together as a pair for row sets which may be large, or for cases
|
||||
where you wish to return rows as they arrive.
|
||||
<literal>spi_fetchrow</literal> works <emphasis>only</emphasis> with
|
||||
<literal>spi_query</literal>. The following example illustrates how
|
||||
@ -687,7 +687,7 @@ $$ LANGUAGE plperl;
|
||||
<term><literal>@{$_TD->{args}}</literal></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Arguments of the trigger function. Does not exist if $_TD->{argc} is 0.
|
||||
Arguments of the trigger function. Does not exist if <literal>$_TD->{argc}</literal> is 0.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -787,7 +787,7 @@ CREATE TRIGGER test_valid_id_trig
|
||||
</para>
|
||||
<para>
|
||||
A similar problem occurs if a set-returning function passes a
|
||||
large set of rows back to postgres via <literal>return</literal>. You
|
||||
large set of rows back to PostgreSQL via <literal>return</literal>. You
|
||||
can avoid this problem too by instead using
|
||||
<literal>return_next</literal> for each row returned, as shown
|
||||
previously.
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/plpgsql.sgml,v 1.79 2005/10/21 05:11:23 neilc Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/plpgsql.sgml,v 1.80 2005/11/04 23:14:00 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="plpgsql">
|
||||
@ -986,7 +986,7 @@ $$ LANGUAGE plpgsql;
|
||||
<application>PL/pgSQL</application> interpreter casts this
|
||||
string to the <type>timestamp</type> type by calling the
|
||||
<function>text_out</function> and <function>timestamp_in</function>
|
||||
functions for the conversion. So, the computed timestamp is updated
|
||||
functions for the conversion. So, the computed time stamp is updated
|
||||
on each execution as the programmer expects.
|
||||
</para>
|
||||
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/create_aggregate.sgml,v 1.32 2005/04/12 04:26:15 tgl Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/create_aggregate.sgml,v 1.33 2005/11/04 23:14:02 petere Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -143,11 +143,11 @@ SELECT col FROM tab ORDER BY col USING sortop LIMIT 1;
|
||||
</programlisting>
|
||||
Further assumptions are that the aggregate ignores null inputs, and that
|
||||
it delivers a null result if and only if there were no non-null inputs.
|
||||
Ordinarily, a datatype's <literal><</> operator is the proper sort
|
||||
Ordinarily, a data type's <literal><</> operator is the proper sort
|
||||
operator for <function>MIN</>, and <literal>></> is the proper sort
|
||||
operator for <function>MAX</>. Note that the optimization will never
|
||||
actually take effect unless the specified operator is the LessThan or
|
||||
GreaterThan strategy member of a btree index opclass.
|
||||
actually take effect unless the specified operator is the <quote>less than</quote> or
|
||||
<quote>greater than</quote> strategy member of a B-tree index operator class.
|
||||
</para>
|
||||
</refsect1>
|
||||
|
||||
@ -243,7 +243,7 @@ SELECT col FROM tab ORDER BY col USING sortop LIMIT 1;
|
||||
The associated sort operator for a <function>MIN</>- or
|
||||
<function>MAX</>-like aggregate.
|
||||
This is just an operator name (possibly schema-qualified).
|
||||
The operator is assumed to have the same input datatypes as
|
||||
The operator is assumed to have the same input data types as
|
||||
the aggregate.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/create_domain.sgml,v 1.25 2005/11/01 21:09:50 tgl Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/create_domain.sgml,v 1.26 2005/11/04 23:14:02 petere Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -58,7 +58,7 @@ where <replaceable class="PARAMETER">constraint</replaceable> is:
|
||||
<caution>
|
||||
<para>
|
||||
At present, declaring a function result value as a domain
|
||||
is pretty dangerous, because none of the PLs enforce domain constraints
|
||||
is pretty dangerous, because none of the procedural languages enforce domain constraints
|
||||
on their results. You'll need to make sure that the function code itself
|
||||
respects the constraints. In <application>PL/pgSQL</>, one possible
|
||||
workaround is to explicitly cast the result value to the domain type
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/pg_ctl-ref.sgml,v 1.31 2005/02/21 02:13:26 neilc Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/pg_ctl-ref.sgml,v 1.32 2005/11/04 23:14:02 petere Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -308,7 +308,7 @@ PostgreSQL documentation
|
||||
<term><option>-U <replaceable class="parameter">username</replaceable></option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Username for the user to start the service. For domain users, use the
|
||||
User name for the user to start the service. For domain users, use the
|
||||
format <literal>DOMAIN\username</literal>.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/pg_resetxlog.sgml,v 1.11 2005/06/08 15:50:21 tgl Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/pg_resetxlog.sgml,v 1.12 2005/11/04 23:14:02 petere Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -61,7 +61,7 @@ PostgreSQL documentation
|
||||
by specifying the <literal>-f</> (force) switch. In this case plausible
|
||||
values will be substituted for the missing data. Most of the fields can be
|
||||
expected to match, but manual assistance may be needed for the next OID,
|
||||
next transaction ID, next multi-transaction ID and offset,
|
||||
next transaction ID, next multitransaction ID and offset,
|
||||
WAL starting address, and database locale fields.
|
||||
The first five of these can be set using the switches discussed below.
|
||||
<command>pg_resetxlog</command>'s own environment is the source for its
|
||||
@ -78,8 +78,8 @@ PostgreSQL documentation
|
||||
<para>
|
||||
The <literal>-o</>, <literal>-x</>, <literal>-m</>, <literal>-O</>,
|
||||
and <literal>-l</>
|
||||
switches allow the next OID, next transaction ID, next multi-transaction
|
||||
ID, next multi-transaction offset, and WAL starting address values to
|
||||
switches allow the next OID, next transaction ID, next multitransaction
|
||||
ID, next multitransaction offset, and WAL starting address values to
|
||||
be set manually. These are only needed when
|
||||
<command>pg_resetxlog</command> is unable to determine appropriate values
|
||||
by reading <filename>pg_control</>. Safe values may be determined as
|
||||
@ -102,7 +102,7 @@ PostgreSQL documentation
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
A safe value for the next multi-transaction ID (<literal>-m</>)
|
||||
A safe value for the next multitransaction ID (<literal>-m</>)
|
||||
may be determined by looking for the numerically largest
|
||||
file name in the directory <filename>pg_multixact/offsets</> under the
|
||||
data directory, adding one, and then multiplying by 65536. As above,
|
||||
@ -113,7 +113,7 @@ PostgreSQL documentation
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
A safe value for the next multi-transaction offset (<literal>-O</>)
|
||||
A safe value for the next multitransaction offset (<literal>-O</>)
|
||||
may be determined by looking for the numerically largest
|
||||
file name in the directory <filename>pg_multixact/members</> under the
|
||||
data directory, adding one, and then multiplying by 65536. As above,
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/psql-ref.sgml,v 1.153 2005/11/01 21:09:50 tgl Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/psql-ref.sgml,v 1.154 2005/11/04 23:14:02 petere Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -2015,7 +2015,7 @@ bar
|
||||
<term><varname>HISTFILE</varname></term>
|
||||
<listitem>
|
||||
<para>
|
||||
The filename that will be used to store the history list. The default
|
||||
The file name that will be used to store the history list. The default
|
||||
value is <filename>~/.psql_history</filename>. For example, putting
|
||||
<programlisting>
|
||||
\set HISTFILE ~/.psql_history- :DBNAME
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/release.sgml,v 1.399 2005/11/04 22:21:33 momjian Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/release.sgml,v 1.400 2005/11/04 23:14:00 petere Exp $
|
||||
|
||||
Typical markup:
|
||||
|
||||
@ -285,7 +285,8 @@ pg_[A-Za-z0-9_] <application>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Cause input of a zero-length string ('') for float4/float8/oid
|
||||
Cause input of a zero-length string (<literal>''</literal>) for
|
||||
<type>float4</type>/<type>float8</type>/<type>oid</type>
|
||||
to throw an error, rather than treating it as a zero (Neil)
|
||||
</para>
|
||||
<para>
|
||||
@ -321,7 +322,7 @@ pg_[A-Za-z0-9_] <application>
|
||||
backslash in a string literal as introducing a special escape sequence,
|
||||
e.g. <literal>\n</> or <literal>\010</>.
|
||||
While this allows easy entry of special values, it is
|
||||
non-standard and makes porting of applications from other
|
||||
nonstandard and makes porting of applications from other
|
||||
databases more difficult. For this reason, the
|
||||
<productname>PostgreSQL</productname> project is planning to
|
||||
remove the special meaning of backslashes in strings. For
|
||||
@ -538,7 +539,7 @@ psql -t -f fixseq.sql db1 | psql -e db1
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Improve GiST and rtree index performance (Neil)
|
||||
Improve GiST and R-tree index performance (Neil)
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
@ -579,7 +580,7 @@ psql -t -f fixseq.sql db1 | psql -e db1
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Allow non-consecutive index columns to be used in a multi-column
|
||||
Allow nonconsecutive index columns to be used in a multicolumn
|
||||
index (Tom)
|
||||
</para>
|
||||
<para>
|
||||
@ -733,7 +734,7 @@ psql -t -f fixseq.sql db1 | psql -e db1
|
||||
<listitem>
|
||||
<para>
|
||||
Add configuration parameter <varname>krb_server_hostname</> so
|
||||
that the server hostname can be specified as part of service
|
||||
that the server host name can be specified as part of service
|
||||
principal (Todd Kover)
|
||||
</para>
|
||||
<para>
|
||||
@ -1639,7 +1640,7 @@ psql -t -f fixseq.sql db1 | psql -e db1
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Allow Perl non-fatal warnings to generate <command>NOTICE</>
|
||||
Allow Perl nonfatal warnings to generate <command>NOTICE</>
|
||||
messages (Andrew)
|
||||
</para>
|
||||
</listitem>
|
||||
@ -1962,7 +1963,7 @@ psql -t -f fixseq.sql db1 | psql -e db1
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Allow IPv6 connections to be used on Win32 (Andrew)
|
||||
Allow IPv6 connections to be used on Windows (Andrew)
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
@ -2711,7 +2712,7 @@ typedefs (Michael)</para></listitem>
|
||||
<para>
|
||||
<command>COPY</command> can now read and write
|
||||
comma-separated-value files. It has the flexibility to
|
||||
interpret non-standard quoting and separation characters too.
|
||||
interpret nonstandard quoting and separation characters too.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -2756,7 +2757,7 @@ typedefs (Michael)</para></listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Non-deferred <option>AFTER</> triggers are now fired immediately
|
||||
Nondeferred <option>AFTER</> triggers are now fired immediately
|
||||
after completion of the triggering query, rather than upon
|
||||
finishing the current interactive command. This makes a
|
||||
difference when the triggering query occurred within a function:
|
||||
@ -2838,7 +2839,7 @@ typedefs (Michael)</para></listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Updating an element or slice of a NULL array value now produces
|
||||
a non-NULL array result, namely an array containing
|
||||
a nonnull array result, namely an array containing
|
||||
just the assigned-to positions.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -2881,7 +2882,7 @@ typedefs (Michael)</para></listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
<type>CIDR</> values now must have their non-masked bits be zero.
|
||||
<type>CIDR</> values now must have their nonmasked bits be zero.
|
||||
For example, we no longer allow
|
||||
<literal>204.248.199.1/31</literal> as a <type>CIDR</> value. Such
|
||||
values should never have been accepted by
|
||||
@ -3168,7 +3169,7 @@ typedefs (Michael)</para></listitem>
|
||||
</para>
|
||||
<para>
|
||||
This feature allows more flexibility in generating statistics
|
||||
for non-standard data types.
|
||||
for nonstandard data types.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
@ -3920,7 +3921,7 @@ typedefs (Michael)</para></listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Reject non-rectangular array values as erroneous (Joe)
|
||||
Reject nonrectangular array values as erroneous (Joe)
|
||||
</para>
|
||||
<para>
|
||||
Formerly, <function>array_in</> would silently build a
|
||||
@ -4182,7 +4183,7 @@ typedefs (Michael)</para></listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Require <type>CIDR</> values to have all non-masked bits be zero
|
||||
Require <type>CIDR</> values to have all nonmasked bits be zero
|
||||
(Kevin Brintnall)
|
||||
</para>
|
||||
</listitem>
|
||||
@ -4219,13 +4220,13 @@ typedefs (Michael)</para></listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Non-deferred <option>AFTER</> triggers are now fired immediately
|
||||
Nondeferred <option>AFTER</> triggers are now fired immediately
|
||||
after completion of the triggering query, rather than upon
|
||||
finishing the current interactive command. This makes a difference
|
||||
when the triggering query occurred within a function: the trigger
|
||||
is invoked before the function proceeds to its next operation. For
|
||||
example, if a function inserts a new row into a table, any
|
||||
non-deferred foreign key checks occur before proceeding with the
|
||||
nondeferred foreign key checks occur before proceeding with the
|
||||
function.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -4758,7 +4759,7 @@ typedefs (Michael)</para></listitem>
|
||||
backend executables too (Bruce)
|
||||
</para>
|
||||
<para>
|
||||
Unixware cannot mix threaded and non-threaded object files in the
|
||||
Unixware cannot mix threaded and nonthreaded object files in the
|
||||
same executable, so everything must be compiled as threaded.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/rowtypes.sgml,v 2.5 2005/01/22 22:56:36 momjian Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/rowtypes.sgml,v 2.6 2005/11/04 23:14:01 petere Exp $ -->
|
||||
|
||||
<sect1 id="rowtypes">
|
||||
<title>Composite Types</title>
|
||||
@ -175,7 +175,7 @@ SELECT item.name FROM on_hand WHERE item.price > 9.99;
|
||||
SELECT (item).name FROM on_hand WHERE (item).price > 9.99;
|
||||
</programlisting>
|
||||
|
||||
or if you need to use the table name as well (for instance in a multi-table
|
||||
or if you need to use the table name as well (for instance in a multitable
|
||||
query), like this:
|
||||
|
||||
<programlisting>
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/runtime.sgml,v 1.356 2005/10/26 12:55:07 momjian Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/runtime.sgml,v 1.357 2005/11/04 23:14:01 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter Id="runtime">
|
||||
@ -854,7 +854,7 @@ options SEMMAP=256
|
||||
<para>
|
||||
Older distributions may not have the <command>sysctl</command> program,
|
||||
but equivalent changes can be made by manipulating the
|
||||
<filename>/proc</filename> filesystem:
|
||||
<filename>/proc</filename> file system:
|
||||
<screen>
|
||||
<prompt>$</prompt> <userinput>echo 134217728 >/proc/sys/kernel/shmmax</userinput>
|
||||
<prompt>$</prompt> <userinput>echo 2097152 >/proc/sys/kernel/shmall</userinput>
|
||||
@ -1357,19 +1357,19 @@ $ <userinput>kill -INT `head -1 /usr/local/pgsql/data/postmaster.pid`</userinput
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
On Linux, encryption can be layered on top of a filesystem mount
|
||||
On Linux, encryption can be layered on top of a file system mount
|
||||
using a <quote>loopback device</quote>. This allows an entire
|
||||
filesystem partition be encrypted on disk, and decrypted by the
|
||||
file system partition be encrypted on disk, and decrypted by the
|
||||
operating system. On FreeBSD, the equivalent facility is called
|
||||
GEOM Based Disk Encryption, or <acronym>gbde</acronym>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
This mechanism prevents unecrypted data from being read from the
|
||||
This mechanism prevents unencrypted data from being read from the
|
||||
drives if the drives or the entire computer is stolen. This does
|
||||
not protect against attacks while the filesystem is mounted,
|
||||
not protect against attacks while the file system is mounted,
|
||||
because when mounted, the operating system provides an unencrypted
|
||||
view of the data. However, to mount the filesystem, you need some
|
||||
view of the data. However, to mount the file system, you need some
|
||||
way for the encryption key to be passed to the operating system,
|
||||
and sometimes the key is stored somewhere on the host that mounts
|
||||
the disk.
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/storage.sgml,v 1.7 2005/09/01 20:01:53 tgl Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/storage.sgml,v 1.8 2005/11/04 23:14:02 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="storage">
|
||||
@ -75,7 +75,7 @@ Item
|
||||
|
||||
<row>
|
||||
<entry><filename>pg_multixact</></entry>
|
||||
<entry>Subdirectory containing multi-transaction status data
|
||||
<entry>Subdirectory containing multitransaction status data
|
||||
(used for shared row locks)</entry>
|
||||
</row>
|
||||
|
||||
@ -331,7 +331,7 @@ more often be done entirely in memory. A little test showed that a table
|
||||
containing typical HTML pages and their URLs was stored in about half of the
|
||||
raw data size including the <acronym>TOAST</> table, and that the main table
|
||||
contained only about 10% of the entire data (the URLs and some small HTML
|
||||
pages). There was no runtime difference compared to an un-<acronym>TOAST</>ed
|
||||
pages). There was no run time difference compared to an un-<acronym>TOAST</>ed
|
||||
comparison table, in which all the HTML pages were cut down to 7Kb to fit.
|
||||
</para>
|
||||
|
||||
@ -663,7 +663,7 @@ data. Empty in ordinary tables.</entry>
|
||||
<structfield>attlen</structfield> and <structfield>attalign</structfield>.
|
||||
There is no way to directly get a
|
||||
particular attribute, except when there are only fixed width fields and no
|
||||
NULLs. All this trickery is wrapped up in the functions
|
||||
null values. All this trickery is wrapped up in the functions
|
||||
<firstterm>heap_getattr</firstterm>, <firstterm>fastgetattr</firstterm>
|
||||
and <firstterm>heap_getsysattr</firstterm>.
|
||||
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/syntax.sgml,v 1.104 2005/10/23 19:29:49 tgl Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/syntax.sgml,v 1.105 2005/11/04 23:14:02 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="sql-syntax">
|
||||
@ -549,7 +549,7 @@ CAST ( '<replaceable>string</replaceable>' AS <replaceable>type</replaceable> )
|
||||
The <literal>CAST()</> syntax conforms to SQL. The
|
||||
<literal><replaceable>type</replaceable> '<replaceable>string</replaceable>'</literal>
|
||||
syntax is a generalization of the standard: SQL specifies this syntax only
|
||||
for a few datatypes, but <productname>PostgreSQL</productname> allows it
|
||||
for a few data types, but <productname>PostgreSQL</productname> allows it
|
||||
for all types. The syntax with
|
||||
<literal>::</literal> is historical <productname>PostgreSQL</productname>
|
||||
usage, as is the function-call syntax.
|
||||
@ -1148,7 +1148,7 @@ CREATE FUNCTION dept(text) RETURNS dept
|
||||
parenthesized, but the parentheses may be omitted when the expression
|
||||
to be subscripted is just a column reference or positional parameter.
|
||||
Also, multiple subscripts can be concatenated when the original array
|
||||
is multi-dimensional.
|
||||
is multidimensional.
|
||||
For example,
|
||||
|
||||
<programlisting>
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/trigger.sgml,v 1.44 2005/10/13 21:09:38 tgl Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/trigger.sgml,v 1.45 2005/11/04 23:14:02 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="triggers">
|
||||
@ -141,7 +141,7 @@ $PostgreSQL: pgsql/doc/src/sgml/trigger.sgml,v 1.44 2005/10/13 21:09:38 tgl Exp
|
||||
Typically, row before triggers are used for checking or
|
||||
modifying the data that will be inserted or updated. For example,
|
||||
a before trigger might be used to insert the current time into a
|
||||
timestamp column, or to check that two elements of the row are
|
||||
<type>timestamp</type> column, or to check that two elements of the row are
|
||||
consistent. Row after triggers are most sensibly
|
||||
used to propagate the updates to other tables, or make consistency
|
||||
checks against other tables. The reason for this division of labor is
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/typeconv.sgml,v 1.44 2005/06/26 22:05:36 tgl Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/typeconv.sgml,v 1.45 2005/11/04 23:14:02 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter Id="typeconv">
|
||||
@ -738,7 +738,7 @@ into the destination column. The implementation function for such a cast
|
||||
always takes an extra parameter of type <type>integer</type>, which receives
|
||||
the destination column's declared length (actually, its
|
||||
<structfield>atttypmod</> value; the interpretation of
|
||||
<structfield>atttypmod</> varies for different datatypes). The cast function
|
||||
<structfield>atttypmod</> varies for different data types). The cast function
|
||||
is responsible for applying any length-dependent semantics such as size
|
||||
checking or truncation.
|
||||
</para>
|
||||
|
||||
@ -1,20 +1,29 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/wal.sgml,v 1.37 2005/10/22 21:56:07 tgl Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/wal.sgml,v 1.38 2005/11/04 23:14:02 petere Exp $ -->
|
||||
|
||||
<chapter id="reliability">
|
||||
<title>Reliability</title>
|
||||
<chapter id="wal">
|
||||
<title>Reliability and the Write-Ahead Log</title>
|
||||
|
||||
<para>
|
||||
This chapter explain how the Write-Ahead Log is used to obtain
|
||||
efficient, reliable operation.
|
||||
</para>
|
||||
|
||||
<sect1 id="wal-reliability">
|
||||
<title>Reliability</title>
|
||||
|
||||
<para>
|
||||
Reliability is a major feature of any serious database system, and
|
||||
<productname>PostgreSQL</> does everything possible to guarantee
|
||||
reliable operation. One aspect of reliable operation is that all data
|
||||
recorded by a committed transaction should be stored in a non-volatile area
|
||||
that is safe from power loss, operating system failure, and hardware
|
||||
failure (except failure of the non-volatile area itself, of course).
|
||||
Successfully writing the data to the computer's permanent storage
|
||||
(disk drive or equivalent) ordinarily meets this requirement.
|
||||
In fact, even if a computer is fatally damaged, if
|
||||
the disk drives survive they can be moved to another computer with
|
||||
similar hardware and all committed transactions will remain intact.
|
||||
Reliability is an important property of any serious database
|
||||
system, and <productname>PostgreSQL</> does everything possible to
|
||||
guarantee reliable operation. One aspect of reliable operation is
|
||||
that all data recorded by a committed transaction should be stored
|
||||
in a nonvolatile area that is safe from power loss, operating
|
||||
system failure, and hardware failure (except failure of the
|
||||
nonvolatile area itself, of course). Successfully writing the data
|
||||
to the computer's permanent storage (disk drive or equivalent)
|
||||
ordinarily meets this requirement. In fact, even if a computer is
|
||||
fatally damaged, if the disk drives survive they can be moved to
|
||||
another computer with similar hardware and all committed
|
||||
transactions will remain intact.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -76,17 +85,13 @@
|
||||
permanent storage <emphasis>before</> modifying the actual page on
|
||||
disk. By doing this, during crash recovery <productname>PostgreSQL</> can
|
||||
restore partially-written pages. If you have a battery-backed disk
|
||||
controller or filesystem software (e.g., Reiser4) that prevents partial
|
||||
controller or file-system software (e.g., Reiser4) that prevents partial
|
||||
page writes, you can turn off this page imaging by using the
|
||||
<xref linkend="guc-full-page-writes"> parameter.
|
||||
</para>
|
||||
</sect1>
|
||||
|
||||
<para>
|
||||
The following sections explain how the Write-Ahead Log is used to
|
||||
obtain efficient, reliable operation.
|
||||
</para>
|
||||
|
||||
<sect1 id="wal">
|
||||
<sect1 id="wal-intro">
|
||||
<title>Write-Ahead Logging (<acronym>WAL</acronym>)</title>
|
||||
|
||||
<indexterm zone="wal">
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/xoper.sgml,v 1.33 2005/01/23 00:30:18 momjian Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/xoper.sgml,v 1.34 2005/11/04 23:14:02 petere Exp $
|
||||
-->
|
||||
|
||||
<sect1 id="xoper">
|
||||
@ -347,7 +347,7 @@ table1.column1 OP table2.column2
|
||||
in a hash index operator class. This is not enforced when you create
|
||||
the operator, since of course the referencing operator class couldn't
|
||||
exist yet. But attempts to use the operator in hash joins will fail
|
||||
at runtime if no such operator class exists. The system needs the
|
||||
at run time if no such operator class exists. The system needs the
|
||||
operator class to find the data-type-specific hash function for the
|
||||
operator's input data type. Of course, you must also supply a suitable
|
||||
hash function before you can create the operator class.
|
||||
@ -479,7 +479,7 @@ table1.column1 OP table2.column2
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Bizarre results will ensue at runtime if the four comparison
|
||||
Bizarre results will ensue at run time if the four comparison
|
||||
operators you name do not sort the data values compatibly.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user