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>
</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
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
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>
<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>
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/">
<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>,
</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>
</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>
</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>
</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>
</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>
<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>
</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>
</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>
<para>
Do an initial login to the <productname>CVS</productname> server:
+<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.
<step>
<para>
Fetch the <productname>PostgreSQL</productname> sources:
+<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>
Whenever you want to update to the latest <productname>CVS</productname> sources,
<command>cd</command> into
the <filename>pgsql</filename> subdirectory, and issue
-$ 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
You can save yourself some typing by making a file <filename>.cvsrc</filename>
in your home directory that contains
+<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
-$ cvs update
- </programlisting>
+<programlisting>
+cvs update
+</programlisting>
to update your files.
</para>
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
-$ 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.
sources that make up release 6_4 of the module `tc' at any time in the
future:
-$ 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.
So, to create the 6.4 release
I did the following:
-$ 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>
First, create two subdirectories, RELEASE and CURRENT, so that you don't
mix up the two. Then do:
+<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,
<para>
After you've done the initial checkout on a branch
-$ 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>
cvs commit
- </programlisting>
+</programlisting>
while inside of it, the patch is applied to the branch and
<emphasis>only</emphasis> the branch.
<filename>/opt/postgres/cvs/</filename>. If you intend to keep your
repository in <filename>/home/cvs/</filename>, then put
+<programlisting>
setenv CVSROOT /home/cvs
- </programlisting>
+</programlisting>
in your <filename>.cshrc</filename> file, or a similar line in
your <filename>.bashrc</filename> or
Once <envar>CVSROOT</envar> is set, then this can be done with a
single command:
-$ 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>
$ ls $CVSROOT
CVSROOT/
- </programlisting>
+</programlisting>
</para>
</sect2>
<application>cvsup</application> is in your path; on most systems
you can do this by typing
+<programlisting>
which cvsup
- </programlisting>
+</programlisting>
Then, simply run
<application>cvsup</application> using:
-$ 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,
modified for a specific installation, and which maintains a full
local <productname>CVS</productname> repository:
+<programlisting>
# This file represents the standard CVSup distribution file
# for the <productname>PostgreSQL</> ORDBMS project
# Modified by lockhart@fourpalms.org 1997-08-28
# pgsql-doc
# pgsql-perl5
# pgsql-src
-
- </programlisting>
+</programlisting>
</para>
<para>
ftp site</ulink>
which will fetch the current snapshot only:
+<programlisting>
# This file represents the standard CVSup distribution file
# for the <productname>PostgreSQL</> ORDBMS project
#
# pgsql-doc
# pgsql-perl5
# pgsql-src
-
- </programlisting>
+</programlisting>
</para>
</sect2>
If the binary is in the top level of the tar file, then simply
unpack the tar file into your target directory:
-$ 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>
<para>
Ensure that the new binaries are in your path.
+<programlisting>
$ rehash
$ which cvsup
$ set path=(<replaceable>path to cvsup</replaceable> $path)
$ which cvsup
/usr/local/bin/cvsup
- </programlisting>
+</programlisting>
</para>
</step>
</procedure>
<para>
Install the Modula-3 rpms:
+<programlisting>
# rpm -Uvh pm3*.rpm
- </programlisting>
+</programlisting>
</para>
</step>
</substeps>
<para>
Unpack the cvsup distribution:
+<programlisting>
# cd /usr/local/src
# tar zxf cvsup-16.0.tar.gz
- </programlisting>
+</programlisting>
</para>
</step>
Build the cvsup distribution, suppressing the GUI interface
feature to avoid requiring X11 libraries:
+<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>
# make M3FLAGS="-DNOGUI -DSTATIC"
- </programlisting>
+</programlisting>
</para>
</step>
<para>
Install the built binary:
+<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:
--->
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
</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:
<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>
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
<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 )
<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>
<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
<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>
</para>
<note>
<para>
- On Win
32, if the <application>ecpg</> libraries and an application are
+ On Win
dows, 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>
<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>
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.
</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>
(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>
<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>
<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>
<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>
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
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.
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</>
<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>
</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">
</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');
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>
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:
<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>
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
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,
<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
<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>
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>
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.
</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
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>
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>
<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
</para>
<note>
<para>
-On Win
32, if the <application>libpq</> library and an application are
+On Win
dows, 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>
<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
</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>
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>
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>
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>
<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
</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
<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>
</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.
<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>
</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>
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>
<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
<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>
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
<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
<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,
<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,
<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
<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>
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
<listitem>
<para>
- Improve GiST and rtree index performance (Neil)
+ Improve GiST and R-tree index performance (Neil)
</para>
</listitem>
<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>
<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>
<listitem>
<para>
- Allow Perl non-fatal warnings to generate <command>NOTICE</>
+ Allow Perl nonfatal warnings to generate <command>NOTICE</>
messages (Andrew)
</para>
</listitem>
<listitem>
<para>
- Allow IPv6 connections to be used on Win32 (Andrew)
+ Allow IPv6 connections to be used on Windows (Andrew)
</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>
<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:
<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>
<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
</para>
<para>
This feature allows more flexibility in generating statistics
- for non-standard data types.
+ for nonstandard data types.
</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
<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>
<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>
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>
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>
<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>
<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.
<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>
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>
<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>.
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.
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>
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
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>
<!-- $PostgreSQL$ -->
-<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>
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">
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.
<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>
projects / users / bernd / postgres.git / commitdiff