Skip to content

P
Postgres FD Implementation
Commit bf62b1a0 authored by Bruce Momjian's avatar Bruce Momjian
Browse files
Options

Proofreading improvements for the Administration documentation book.

parent 1e4cc384
Expand all Hide whitespace changes
Inline Side-by-side
Showing with 684 additions and 673 deletions
doc/src/sgml/backup.sgml
View file @ bf62b1a0
This diff is collapsed.
doc/src/sgml/catalogs.sgml
View file @ bf62b1a0
<!-- $PostgreSQL: pgsql/doc/src/sgml/catalogs.sgml,v 2.219 2010/01/22 16:40:18 rhaas Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/catalogs.sgml,v 2.220 2010/02/03 17:25:05 momjian Exp $ -->
<!--
Documentation of the system catalogs, directed toward PostgreSQL developers
-->
......@@ -5569,7 +5569,9 @@
inserted before a datum of this type so that it begins on the
specified boundary. The alignment reference is the beginning
of the first datum in the sequence.
</para><para>
</para>
<para>
Possible values are:
<itemizedlist>
<listitem>
......
doc/src/sgml/charset.sgml
View file @ bf62b1a0
<!-- $PostgreSQL: pgsql/doc/src/sgml/charset.sgml,v 2.95 2009/05/18 08:59:28 petere Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/charset.sgml,v 2.96 2010/02/03 17:25:05 momjian Exp $ -->
<chapter id="charset">
<title>Localization</>
......@@ -6,8 +6,8 @@
<para>
This chapter describes the available localization features from the
point of view of the administrator.
<productname>PostgreSQL</productname> supports localization with
two approaches:
<productname>PostgreSQL</productname> supports two localization
facilities:
<itemizedlist>
<listitem>
......@@ -67,10 +67,10 @@ initdb --locale=sv_SE
(<literal>sv</>) as spoken
in Sweden (<literal>SE</>). Other possibilities might be
<literal>en_US</> (U.S. English) and <literal>fr_CA</> (French
Canadian). If more than one character set can be useful for a
Canadian). If more than one character set can be used for a
locale then the specifications look like this:
<literal>cs_CZ.ISO8859-2</>. What locales are available under what
names on your system depends on what was provided by the operating
<literal>cs_CZ.ISO8859-2</>. What locales are available on your
system under what names depends on what was provided by the operating
system vendor and what was installed. On most Unix systems, the command
<literal>locale -a</> will provide a list of available locales.
Windows uses more verbose locale names, such as <literal>German_Germany</>
......@@ -80,8 +80,8 @@ initdb --locale=sv_SE
<para>
Occasionally it is useful to mix rules from several locales, e.g.,
use English collation rules but Spanish messages. To support that, a
set of locale subcategories exist that control only a certain
aspect of the localization rules:
set of locale subcategories exist that control only certain
aspects of the localization rules:
<informaltable>
<tgroup cols="2">
......@@ -127,13 +127,13 @@ initdb --locale=sv_SE
</para>
<para>
The nature of some locale categories is that their value has to be
Some locale categories must have their values
fixed when the database is created. You can use different settings
for different databases, but once a database is created, you cannot
change them for that database anymore. <literal>LC_COLLATE</literal>
and <literal>LC_CTYPE</literal> are these categories. They affect
and <literal>LC_CTYPE</literal> are these type of categories. They affect
the sort order of indexes, so they must be kept fixed, or indexes on
text columns will become corrupt. The default values for these
text columns would become corrupt. The default values for these
categories are determined when <command>initdb</command> is run, and
those values are used when new databases are created, unless
specified otherwise in the <command>CREATE DATABASE</command> command.
......@@ -146,7 +146,7 @@ initdb --locale=sv_SE
linkend="runtime-config-client-format"> for details). The values
that are chosen by <command>initdb</command> are actually only written
into the configuration file <filename>postgresql.conf</filename> to
serve as defaults when the server is started. If you delete these
serve as defaults when the server is started. If you disable these
assignments from <filename>postgresql.conf</filename> then the
server will inherit the settings from its execution environment.
</para>
......@@ -178,7 +178,7 @@ initdb --locale=sv_SE
settings for the purpose of setting the language of messages. If
in doubt, please refer to the documentation of your operating
system, in particular the documentation about
<application>gettext</>, for more information.
<application>gettext</>.
</para>
</note>
......@@ -320,8 +320,9 @@ initdb --locale=sv_SE
<para>
An important restriction, however, is that each database's character set
must be compatible with the database's <envar>LC_CTYPE</> and
<envar>LC_COLLATE</> locale settings. For <literal>C</> or
must be compatible with the database's <envar>LC_CTYPE</> (character
classification) and <envar>LC_COLLATE</> (string sort order) locale
settings. For <literal>C</> or
<literal>POSIX</> locale, any character set is allowed, but for other
locales there is only one character set that will work correctly.
(On Windows, however, UTF-8 encoding can be used with any locale.)
......@@ -543,7 +544,7 @@ initdb --locale=sv_SE
<entry>LATIN1 with Euro and accents</entry>
<entry>Yes</entry>
<entry>1</entry>
<entry>ISO885915</entry>
<entry><literal>ISO885915</></entry>
</row>
<row>
<entry><literal>LATIN10</literal></entry>
......@@ -694,7 +695,7 @@ initdb --locale=sv_SE
</table>
<para>
Not all <acronym>API</>s support all the listed character sets. For example, the
Not all client <acronym>API</>s support all the listed character sets. For example, the
<productname>PostgreSQL</>
JDBC driver does not support <literal>MULE_INTERNAL</>, <literal>LATIN6</>,
<literal>LATIN8</>, and <literal>LATIN10</>.
......@@ -710,7 +711,7 @@ initdb --locale=sv_SE
much a declaration that a specific encoding is in use, as a declaration
of ignorance about the encoding. In most cases, if you are
working with any non-ASCII data, it is unwise to use the
<literal>SQL_ASCII</> setting, because
<literal>SQL_ASCII</> setting because
<productname>PostgreSQL</productname> will be unable to help you by
converting or validating non-ASCII characters.
</para>
......@@ -720,17 +721,17 @@ initdb --locale=sv_SE
<title>Setting the Character Set</title>
<para>
<command>initdb</> defines the default character set
<command>initdb</> defines the default character set (encoding)
for a <productname>PostgreSQL</productname> cluster. For example,
<screen>
initdb -E EUC_JP
</screen>
sets the default character set (encoding) to
sets the default character set to
<literal>EUC_JP</literal> (Extended Unix Code for Japanese). You
can use <option>--encoding</option> instead of
<option>-E</option> if you prefer to type longer option strings.
<option>-E</option> if you prefer longer option strings.
If no <option>-E</> or <option>--encoding</option> option is
given, <command>initdb</> attempts to determine the appropriate
encoding to use based on the specified or default locale.
......@@ -762,8 +763,8 @@ CREATE DATABASE korean WITH ENCODING 'EUC_KR' LC_COLLATE='ko_KR.euckr' LC_CTYPE=
<para>
The encoding for a database is stored in the system catalog
<literal>pg_database</literal>. You can see it by using the
<option>-l</option> option or the <command>\l</command> command
of <command>psql</command>.
<command>psql</command> <option>-l</option> option or the
<command>\l</command> command.
<screen>
$ <userinput>psql -l</userinput>
......@@ -784,11 +785,11 @@ $ <userinput>psql -l</userinput>
<important>
<para>
On most modern operating systems, <productname>PostgreSQL</productname>
can determine which character set is implied by an <envar>LC_CTYPE</>
can determine which character set is implied by the <envar>LC_CTYPE</>
setting, and it will enforce that only the matching database encoding is
used. On older systems it is your responsibility to ensure that you use
the encoding expected by the locale you have selected. A mistake in
this area is likely to lead to strange misbehavior of locale-dependent
this area is likely to lead to strange behavior of locale-dependent
operations such as sorting.
</para>
......@@ -1190,9 +1191,9 @@ RESET client_encoding;
<para>
If the conversion of a particular character is not possible
&mdash; suppose you chose <literal>EUC_JP</literal> for the
server and <literal>LATIN1</literal> for the client, then some
Japanese characters do not have a representation in
<literal>LATIN1</literal> &mdash; then an error is reported.
server and <literal>LATIN1</literal> for the client, and some
Japanese characters are returned that do not have a representation in
<literal>LATIN1</literal> &mdash; an error is reported.
</para>
<para>
......@@ -1249,7 +1250,8 @@ RESET client_encoding;
<listitem>
<para>
<acronym>UTF</acronym>-8 is defined here.
<acronym>UTF</acronym>-8 (8-bit UCS/Unicode Transformation
Format) is defined here.
</para>
</listitem>
</varlistentry>
......
doc/src/sgml/client-auth.sgml
View file @ bf62b1a0
This diff is collapsed.
doc/src/sgml/config.sgml
View file @ bf62b1a0
This diff is collapsed.
doc/src/sgml/diskusage.sgml
View file @ bf62b1a0
<!-- $PostgreSQL: pgsql/doc/src/sgml/diskusage.sgml,v 1.18 2007/01/31 20:56:16 momjian Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/diskusage.sgml,v 1.19 2010/02/03 17:25:05 momjian Exp $ -->
<chapter id="diskusage">
<title>Monitoring Disk Usage</title>
......@@ -18,10 +18,10 @@
<para>
Each table has a primary heap disk file where most of the data is
stored. If the table has any columns with potentially-wide values,
there is also a <acronym>TOAST</> file associated with the table,
there also might be a <acronym>TOAST</> file associated with the table,
which is used to store values too wide to fit comfortably in the main
table (see <xref linkend="storage-toast">). There will be one index on the
<acronym>TOAST</> table, if present. There might also be indexes associated
<acronym>TOAST</> table, if present. There also might be indexes associated
with the base table. Each table and index is stored in a separate disk
file &mdash; possibly more than one file, if the file would exceed one
gigabyte. Naming conventions for these files are described in <xref
......@@ -29,7 +29,7 @@
</para>
<para>
You can monitor disk space from three ways: using
You can monitor disk space three ways: using
SQL functions listed in <xref linkend="functions-admin-dbsize">,
using <command>VACUUM</> information, and from the command line
using the tools in <filename>contrib/oid2name</>. The SQL functions
......@@ -60,13 +60,15 @@ SELECT relfilenode, relpages FROM pg_class WHERE relname = 'customer';
like the following:
<programlisting>
SELECT relname, relpages
FROM pg_class,
(SELECT reltoastrelid FROM pg_class
WHERE relname = 'customer') ss
WHERE oid = ss.reltoastrelid
OR oid = (SELECT reltoastidxid FROM pg_class
WHERE oid = ss.reltoastrelid)
ORDER BY relname;
FROM pg_class,
(SELECT reltoastrelid
FROM pg_class
WHERE relname = 'customer') AS ss
WHERE oid = ss.reltoastrelid OR
oid = (SELECT reltoastidxid
FROM pg_class
WHERE oid = ss.reltoastrelid)
ORDER BY relname;
relname | relpages
----------------------+----------
......@@ -79,11 +81,11 @@ SELECT relname, relpages
You can easily display index sizes, too:
<programlisting>
SELECT c2.relname, c2.relpages
FROM pg_class c, pg_class c2, pg_index i
WHERE c.relname = 'customer'
AND c.oid = i.indrelid
AND c2.oid = i.indexrelid
ORDER BY c2.relname;
FROM pg_class c, pg_class c2, pg_index i
WHERE c.relname = 'customer' AND
c.oid = i.indrelid AND
c2.oid = i.indexrelid
ORDER BY c2.relname;
relname | relpages
----------------------+----------
......@@ -95,7 +97,9 @@ SELECT c2.relname, c2.relpages
It is easy to find your largest tables and indexes using this
information:
<programlisting>
SELECT relname, relpages FROM pg_class ORDER BY relpages DESC;
SELECT relname, relpages
FROM pg_class
ORDER BY relpages DESC;
relname | relpages
----------------------+----------
......@@ -105,9 +109,8 @@ SELECT relname, relpages FROM pg_class ORDER BY relpages DESC;
</para>
<para>
You can also use <filename>contrib/oid2name</> to show disk usage. See
<filename>README.oid2name</> in that directory for examples. It includes a script that
shows disk usage for each database.
You can also use <filename>contrib/oid2name</> to show disk usage; see
<xref linkend="oid2name"> for more details and examples.
</para>
</sect1>
......@@ -116,7 +119,7 @@ SELECT relname, relpages FROM pg_class ORDER BY relpages DESC;
<para>
The most important disk monitoring task of a database administrator
is to make sure the disk doesn't grow full. A filled data disk will
is to make sure the disk doesn't become full. A filled data disk will
not result in data corruption, but it might prevent useful activity
from occurring. If the disk holding the WAL files grows full, database
server panic and consequent shutdown might occur.
......@@ -140,7 +143,7 @@ SELECT relname, relpages FROM pg_class ORDER BY relpages DESC;
If your system supports per-user disk quotas, then the database
will naturally be subject to whatever quota is placed on the user
the server runs as. Exceeding the quota will have the same bad
effects as running out of space entirely.
effects as running out of disk space entirely.
</para>
</sect1>
</chapter>
doc/src/sgml/high-availability.sgml
View file @ bf62b1a0
<!-- $PostgreSQL: pgsql/doc/src/sgml/high-availability.sgml,v 1.36 2010/01/15 09:18:59 heikki Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/high-availability.sgml,v 1.37 2010/02/03 17:25:05 momjian Exp $ -->
<chapter id="high-availability">
<title>High Availability, Load Balancing, and Replication</title>
......@@ -67,7 +67,7 @@
<para>
Performance must be considered in any choice. There is usually a
trade-off between functionality and
performance. For example, a full synchronous solution over a slow
performance. For example, a fully synchronous solution over a slow
network might cut performance by more than half, while an asynchronous
one might have a minimal performance impact.
</para>
......@@ -89,7 +89,7 @@
Shared disk failover avoids synchronization overhead by having only one
copy of the database. It uses a single disk array that is shared by
multiple servers. If the main database server fails, the standby server
is able to mount and start the database as though it was recovering from
is able to mount and start the database as though it were recovering from
a database crash. This allows rapid failover with no data loss.
</para>
......@@ -149,7 +149,7 @@ protocol to make nodes agree on a serializable transactional order.
<para>
A PITR warm standby server can be kept more up-to-date using the
streaming replication feature built into <productname>PostgreSQL</> 8.5
onwards.
onwards; see <xref linkend="warm-standby">.
</para>
</listitem>
</varlistentry>
......@@ -190,7 +190,7 @@ protocol to make nodes agree on a serializable transactional order.
<para>
If queries are simply broadcast unmodified, functions like
<function>random()</>, <function>CURRENT_TIMESTAMP</>, and
sequences would have different values on different servers.
sequences can have different values on different servers.
This is because each server operates independently, and because
SQL queries are broadcast (and not actual modified rows). If
this is unacceptable, either the middleware or the application
......
doc/src/sgml/install-win32.sgml
View file @ bf62b1a0
<!-- $PostgreSQL: pgsql/doc/src/sgml/install-win32.sgml,v 1.55 2010/01/12 20:13:32 mha Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/install-win32.sgml,v 1.56 2010/02/03 17:25:05 momjian Exp $ -->
<chapter id="install-win32">
<title>Installation from Source Code on <productname>Windows</productname></title>
......@@ -388,7 +388,7 @@
</userinput>
</screen>
To change the schedule used (default is the parallel), append it to the
To change the schedule used (default is parallel), append it to the
command line like:
<screen>
<userinput>
......@@ -544,9 +544,10 @@
Normally you do not need to install any of the client files. You should
place the <filename>libpq.dll</filename> file in the same directory
as your applications executable file. Do not install
<filename>libpq.dll</filename> into your Windows, System or System32
directory unless absolutely necessary.
If this file is installed using a setup program, it should
<filename>libpq.dll</filename> into your <filename>Windows</>,
<filename>System</> or <filename>System32</> directory unless
absolutely necessary.
If this file is installed using a setup program, then it should
be installed with version checking using the
<symbol>VERSIONINFO</symbol> resource included in the file, to
ensure that a newer version of the library is not overwritten.
......
doc/src/sgml/installation.sgml
View file @ bf62b1a0
<!-- $PostgreSQL: pgsql/doc/src/sgml/installation.sgml,v 1.340 2010/01/28 23:59:52 adunstan Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/installation.sgml,v 1.341 2010/02/03 17:25:05 momjian Exp $ -->
<chapter id="installation">
<title><![%standalone-include[<productname>PostgreSQL</>]]>
......@@ -1106,7 +1106,7 @@ su - postgres
a larger segment size. This can be helpful to reduce the number of
file descriptors consumed when working with very large tables.
But be careful not to select a value larger than is supported
by your platform and the filesystem(s) you intend to use. Other
by your platform and the file systems you intend to use. Other
tools you might wish to use, such as <application>tar</>, could
also set limits on the usable file size.
It is recommended, though not absolutely required, that this value
......
doc/src/sgml/maintenance.sgml
View file @ bf62b1a0
This diff is collapsed.
doc/src/sgml/manage-ag.sgml
View file @ bf62b1a0
<!-- $PostgreSQL: pgsql/doc/src/sgml/manage-ag.sgml,v 2.60 2009/12/19 01:49:02 tgl Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/manage-ag.sgml,v 2.61 2010/02/03 17:25:05 momjian Exp $ -->
<chapter id="managing-databases">
<title>Managing Databases</title>
......@@ -25,7 +25,7 @@
A database is a named collection of <acronym>SQL</acronym> objects
(<quote>database objects</quote>). Generally, every database
object (tables, functions, etc.) belongs to one and only one
database. (But there are a few system catalogs, for example
database. (However there are a few system catalogs, for example
<literal>pg_database</>, that belong to a whole cluster and
are accessible from each database within the cluster.) More
accurately, a database is a collection of schemas and the schemas
......@@ -38,15 +38,15 @@
When connecting to the database server, a client must specify in
its connection request the name of the database it wants to connect
to. It is not possible to access more than one database per
connection. (But an application is not restricted in the number of
connections it opens to the same or other databases.) Databases are
connection. However, an application is not restricted in the number of
connections it opens to the same or other databases. Databases are
physically separated and access control is managed at the
connection level. If one <productname>PostgreSQL</> server
instance is to house projects or users that should be separate and
for the most part unaware of each other, it is therefore
recommendable to put them into separate databases. If the projects
or users are interrelated and should be able to use each other's
resources they should be put in the same database, but possibly
resources, they should be put in the same database but possibly
into separate schemas. Schemas are a purely logical structure and who can
access what is managed by the privilege system. More information about
managing schemas is in <xref linkend="ddl-schemas">.
......@@ -94,7 +94,7 @@ CREATE DATABASE <replaceable>name</>;
where <replaceable>name</> follows the usual rules for
<acronym>SQL</acronym> identifiers. The current role automatically
becomes the owner of the new database. It is the privilege of the
owner of a database to remove it later on (which also removes all
owner of a database to remove it later (which also removes all
the objects in it, even if they have a different owner).
</para>
......@@ -123,14 +123,14 @@ CREATE DATABASE <replaceable>name</>;
new database is created within the
cluster, <literal>template1</literal> is essentially cloned.
This means that any changes you make in <literal>template1</> are
propagated to all subsequently created databases. Therefore it is
unwise to use <literal>template1</> for real work, but when
used judiciously this feature can be convenient. More details
propagated to all subsequently created databases. Because of this,
avoid creating objects in <literal>template1</> unless you want them
propagated to every newly created database. More details
appear in <xref linkend="manage-ag-templatedbs">.
</para>
<para>
As a convenience, there is a program that you can
As a convenience, there is a program you can
execute from the shell to create new databases,
<command>createdb</>.<indexterm><primary>createdb</></>
......@@ -143,8 +143,7 @@ createdb <replaceable class="parameter">dbname</replaceable>
exactly as described above.
The <xref linkend="app-createdb"> reference page contains the invocation
details. Note that <command>createdb</> without any arguments will create
a database with the current user name, which might or might not be what
you want.
a database with the current user name.
</para>
<note>
......@@ -155,8 +154,8 @@ createdb <replaceable class="parameter">dbname</replaceable>
</note>
<para>
Sometimes you want to create a database for someone else. That
role should become the owner of the new database, so he can
Sometimes you want to create a database for someone else, and have him
become the owner of the new database, so he can
configure and manage it himself. To achieve that, use one of the
following commands:
<programlisting>
......@@ -167,7 +166,7 @@ CREATE DATABASE <replaceable>dbname</> OWNER <replaceable>rolename</>;
createdb -O <replaceable>rolename</> <replaceable>dbname</>
</programlisting>
from the shell.
You must be a superuser to be allowed to create a database for
Only the superuser is allowed to create a database for
someone else (that is, for a role you are not a member of).
</para>
</sect1>
......@@ -186,7 +185,7 @@ createdb -O <replaceable>rolename</> <replaceable>dbname</>
objects in databases. For example, if you install the procedural
language <application>PL/Perl</> in <literal>template1</>, it will
automatically be available in user databases without any extra
action being taken when those databases are made.
action being taken when those databases are created.
</para>
<para>
......@@ -204,7 +203,7 @@ createdb -O <replaceable>rolename</> <replaceable>dbname</>
<literal>template1</>. This is particularly handy when restoring a
<literal>pg_dump</> dump: the dump script should be restored in a
virgin database to ensure that one recreates the correct contents
of the dumped database, without any conflicts with objects that
of the dumped database, without conflicting with objects that
might have been added to <literal>template1</> later on.
</para>
......@@ -238,8 +237,8 @@ createdb -T template0 <replaceable>dbname</>
The principal limitation is that no other sessions can be connected to
the source database while it is being copied. <command>CREATE
DATABASE</> will fail if any other connection exists when it starts;
otherwise, new connections to the source database are locked out
until <command>CREATE DATABASE</> completes.
during the copy operation, new connections to the source database
are prevented.
</para>
<para>
......@@ -251,9 +250,9 @@ createdb -T template0 <replaceable>dbname</>
cloned by any user with <literal>CREATEDB</> privileges; if it is not set,
only superusers and the owner of the database can clone it.
If <literal>datallowconn</literal> is false, then no new connections
to that database will be allowed (but existing sessions are not killed
to that database will be allowed (but existing sessions are not terminated
simply by setting the flag false). The <literal>template0</literal>
database is normally marked <literal>datallowconn = false</> to prevent modification of it.
database is normally marked <literal>datallowconn = false</> to prevent its modification.
Both <literal>template0</literal> and <literal>template1</literal>
should always be marked with <literal>datistemplate = true</>.
</para>
......@@ -274,7 +273,7 @@ createdb -T template0 <replaceable>dbname</>
The <literal>postgres</> database is also created when a database
cluster is initialized. This database is meant as a default database for
users and applications to connect to. It is simply a copy of
<literal>template1</> and can be dropped and recreated if required.
<literal>template1</> and can be dropped and recreated if necessary.
</para>
</note>
</sect1>
......@@ -294,7 +293,7 @@ createdb -T template0 <replaceable>dbname</>
<acronym>GEQO</acronym> optimizer for a given database, you'd
ordinarily have to either disable it for all databases or make sure
that every connecting client is careful to issue <literal>SET geqo
TO off;</literal>. To make this setting the default within a particular
TO off</literal>. To make this setting the default within a particular
database, you can execute the command:
<programlisting>
ALTER DATABASE mydb SET geqo TO off;
......@@ -306,7 +305,7 @@ ALTER DATABASE mydb SET geqo TO off;
Note that users can still alter this setting during their sessions; it
will only be the default. To undo any such setting, use
<literal>ALTER DATABASE <replaceable>dbname</> RESET
<replaceable>varname</>;</literal>.
<replaceable>varname</></literal>.
</para>
</sect1>
......@@ -387,7 +386,7 @@ dropdb <replaceable class="parameter">dbname</replaceable>
CREATE TABLESPACE fastspace LOCATION '/mnt/sda1/postgresql/data';
</programlisting>
The location must be an existing, empty directory that is owned by
the <productname>PostgreSQL</> system user. All objects subsequently
the <productname>PostgreSQL</> operating system user. All objects subsequently
created within the tablespace will be stored in files underneath this
directory.
</para>
......@@ -405,7 +404,7 @@ CREATE TABLESPACE fastspace LOCATION '/mnt/sda1/postgresql/data';
<para>
Creation of the tablespace itself must be done as a database superuser,
but after that you can allow ordinary database users to make use of it.
but after that you can allow ordinary database users to use it.
To do that, grant them the <literal>CREATE</> privilege on it.
</para>
......@@ -500,8 +499,8 @@ SELECT spcname FROM pg_tablespace;
Although not recommended, it is possible to adjust the tablespace
layout by hand by redefining these links. Two warnings: do not do so
while the server is running; and after you restart the server,
update the <structname>pg_tablespace</> catalog to show the new
locations. (If you do not, <literal>pg_dump</> will continue to show
update the <structname>pg_tablespace</> catalog with the new
locations. (If you do not, <literal>pg_dump</> will continue to output
the old tablespace locations.)
</para>
......
doc/src/sgml/monitoring.sgml
View file @ bf62b1a0
<!-- $PostgreSQL: pgsql/doc/src/sgml/monitoring.sgml,v 1.75 2010/01/28 14:25:41 mha Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/monitoring.sgml,v 1.76 2010/02/03 17:25:05 momjian Exp $ -->
<chapter id="monitoring">
<title>Monitoring Database Activity</title>
......@@ -43,7 +43,7 @@
</indexterm>
<para>
On most platforms, <productname>PostgreSQL</productname> modifies its
On most Unix platforms, <productname>PostgreSQL</productname> modifies its
command title as reported by <command>ps</>, so that individual server
processes can readily be identified. A sample display is
......@@ -61,7 +61,7 @@ postgres 1016 0.1 2.4 6532 3080 pts/1 SN 13:19 0:00 postgres: tgl reg
platforms, as do the details of what is shown. This example is from a
recent Linux system.) The first process listed here is the
master server process. The command arguments
shown for it are the same ones given when it was launched. The next two
shown for it are the same ones used when it was launched. The next two
processes are background worker processes automatically launched by the
master process. (The <quote>stats collector</> process will not be present
if you have set
......@@ -73,22 +73,22 @@ postgres 1016 0.1 2.4 6532 3080 pts/1 SN 13:19 0:00 postgres: tgl reg
postgres: <replaceable>user</> <replaceable>database</> <replaceable>host</> <replaceable>activity</>
</screen>
The user, database, and connection source host items remain the same for
The user, database, and (client) host items remain the same for
the life of the client connection, but the activity indicator changes.
The activity can be <literal>idle</> (i.e., waiting for a client command),
<literal>idle in transaction</> (waiting for client inside a <command>BEGIN</> block),
or a command type name such as <literal>SELECT</>. Also,
<literal>waiting</> is attached if the server process is presently waiting
on a lock held by another server process. In the above example we can infer
<literal>waiting</> is appended if the server process is presently waiting
on a lock held by another session. In the above example we can infer
that process 1003 is waiting for process 1016 to complete its transaction and
thereby release some lock or other.
thereby release some lock.
</para>
<para>
If you have turned off <xref linkend="guc-update-process-title"> then the
activity indicator is not updated; the process title is set only once
when a new process is launched. On some platforms this saves a useful
amount of per-command overhead, on others it's insignificant.
when a new process is launched. On some platforms this saves a measurable
amount of per-command overhead; on others it's insignificant.
</para>
<tip>
......@@ -118,15 +118,15 @@ postgres: <replaceable>user</> <replaceable>database</> <replaceable>host</> <re
is a subsystem that supports collection and reporting of information about
server activity. Presently, the collector can count accesses to tables
and indexes in both disk-block and individual-row terms. It also tracks
total numbers of rows in each table, and the last vacuum and analyze times
the total number of rows in each table, and the last vacuum and analyze times
for each table. It can also count calls to user-defined functions and
the total time spent in each one.
</para>
<para>
<productname>PostgreSQL</productname> also supports determining the exact
<productname>PostgreSQL</productname> also supports reporting of the exact
command currently being executed by other server processes. This is an
independent facility that does not depend on the collector process.
facility independent of the collector process.
</para>
<sect2 id="monitoring-stats-setup">
......@@ -172,7 +172,7 @@ postgres: <replaceable>user</> <replaceable>database</> <replaceable>host</> <re
When the postmaster shuts down, a permanent copy of the statistics
data is stored in the <filename>global</filename> subdirectory. For increased
performance, the parameter <xref linkend="guc-stats-temp-directory"> can
be pointed at a RAM based filesystem, decreasing physical I/O requirements.
be pointed at a RAM-based file system, decreasing physical I/O requirements.
</para>
</sect2>
......@@ -205,9 +205,9 @@ postgres: <replaceable>user</> <replaceable>database</> <replaceable>host</> <re
any of these statistics, it first fetches the most recent report emitted by
the collector process and then continues to use this snapshot for all
statistical views and functions until the end of its current transaction.
So the statistics will appear not to change as long as you continue the
So the statistics will show static information as long as you continue the
current transaction. Similarly, information about the current queries of
all processes is collected when any such information is first requested
all sessions is collected when any such information is first requested
within a transaction, and the same information will be displayed throughout
the transaction.
This is a feature, not a bug, because it allows you to perform several
......@@ -1603,7 +1603,7 @@ Total time (ns) 2312105013
SystemTap uses a different notation for trace scripts than DTrace does,
even though the underlying trace points are compatible. One point worth
noting is that at this writing, SystemTap scripts must reference probe
names using double underlines in place of hyphens. This is expected to
names using double underscores in place of hyphens. This is expected to
be fixed in future SystemTap releases.
</para>
</note>
......
doc/src/sgml/regress.sgml
View file @ bf62b1a0
<!-- $PostgreSQL: pgsql/doc/src/sgml/regress.sgml,v 1.64 2009/08/07 20:50:21 petere Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/regress.sgml,v 1.65 2010/02/03 17:25:06 momjian Exp $ -->
<chapter id="regress">
<title id="regress-title">Regression Tests</title>
......@@ -26,17 +26,14 @@
running server, or using a temporary installation within the build
tree. Furthermore, there is a <quote>parallel</quote> and a
<quote>sequential</quote> mode for running the tests. The
sequential method runs each test script in turn, whereas the
sequential method runs each test script alone, while the
parallel method starts up multiple server processes to run groups
of tests in parallel. Parallel testing gives confidence that
interprocess communication and locking are working correctly. For
historical reasons, the sequential test is usually run against an
existing installation and the parallel method against a temporary
installation, but there are no technical reasons for this.
interprocess communication and locking are working correctly.
</para>
<para>
To run the regression tests after building but before installation,
To run the parallel regression tests after building but before installation,
type:
<screen>
gmake check
......@@ -44,7 +41,7 @@ gmake check
in the top-level directory. (Or you can change to
<filename>src/test/regress</filename> and run the command there.)
This will first build several auxiliary files, such as
some sample user-defined trigger functions, and then run the test driver
sample user-defined trigger functions, and then run the test driver
script. At the end you should see something like:
<screen>
<computeroutput>
......@@ -206,9 +203,9 @@ gmake installcheck
<para>
If you run the tests against a server that was
initialized with a collation-order locale other than C, then
there might be differences due to sort order and follow-up
there might be differences due to sort order and subsequent
failures. The regression test suite is set up to handle this
problem by providing alternative result files that together are
problem by providing alternate result files that together are
known to handle a large number of locales.
</para>
......@@ -270,7 +267,7 @@ gmake check NO_LOCALE=1
results involving mathematical functions of <type>double
precision</type> columns have been observed. The <literal>float8</> and
<literal>geometry</> tests are particularly prone to small differences
across platforms, or even with different compiler optimization options.
across platforms, or even with different compiler optimization setting.
Human eyeball comparison is needed to determine the real
significance of these differences which are usually 10 places to
the right of the decimal point.
......@@ -298,10 +295,10 @@ different order than what appears in the expected file. In most cases
this is not, strictly speaking, a bug. Most of the regression test
scripts are not so pedantic as to use an <literal>ORDER BY</> for every single
<literal>SELECT</>, and so their result row orderings are not well-defined
according to the letter of the SQL specification. In practice, since we are
according to the SQL specification. In practice, since we are
looking at the same queries being executed on the same data by the same
software, we usually get the same result ordering on all platforms, and
so the lack of <literal>ORDER BY</> isn't a problem. Some queries do exhibit
software, we usually get the same result ordering on all platforms,
so the lack of <literal>ORDER BY</> is not a problem. Some queries do exhibit
cross-platform ordering differences, however. When testing against an
already-installed server, ordering differences can also be caused by
non-C locale settings or non-default parameter settings, such as custom values
......@@ -311,8 +308,8 @@ of <varname>work_mem</> or the planner cost parameters.
<para>
Therefore, if you see an ordering difference, it's not something to
worry about, unless the query does have an <literal>ORDER BY</> that your
result is violating. But please report it anyway, so that we can add an
<literal>ORDER BY</> to that particular query and thereby eliminate the bogus
result is violating. However, please report it anyway, so that we can add an
<literal>ORDER BY</> to that particular query to eliminate the bogus
<quote>failure</quote> in future releases.
</para>
......@@ -364,7 +361,7 @@ diff results/random.out expected/random.out
<para>
Since some of the tests inherently produce environment-dependent
results, we have provided ways to specify alternative <quote>expected</>
results, we have provided ways to specify alternate <quote>expected</>
result files. Each regression test can have several comparison files
showing possible results on different platforms. There are two
independent mechanisms for determining which comparison file is used
......@@ -410,7 +407,7 @@ testname:output:platformpattern=comparisonfilename
<programlisting>
float8:out:i.86-.*-openbsd=float8-small-is-zero.out
</programlisting>
which will trigger on any machine for which the output of
which will trigger on any machine where the output of
<command>config.guess</command> matches <literal>i.86-.*-openbsd</literal>.
Other lines
in <filename>resultmap</> select the variant comparison file for other
......
doc/src/sgml/runtime.sgml
View file @ bf62b1a0
This diff is collapsed.
doc/src/sgml/user-manag.sgml
View file @ bf62b1a0
<!-- $PostgreSQL: pgsql/doc/src/sgml/user-manag.sgml,v 1.41 2008/10/28 12:10:42 mha Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/user-manag.sgml,v 1.42 2010/02/03 17:25:06 momjian Exp $ -->
<chapter id="user-manag">
<title>Database Roles and Privileges</title>
......@@ -11,8 +11,7 @@
tables) and can assign privileges on those objects to other roles to
control who has access to which objects. Furthermore, it is possible
to grant <firstterm>membership</> in a role to another role, thus
allowing the member role use of privileges assigned to the role it is
a member of.
allowing the member role to use privileges assigned to another role.
</para>
<para>
......@@ -110,9 +109,9 @@ SELECT rolname FROM pg_roles;
</para>
<para>
Every connection to the database server is made in the name of some
Every connection to the database server is made using the name of some
particular role, and this role determines the initial access privileges for
commands issued on that connection.
commands issued in that connection.
The role name to use for a particular database
connection is indicated by the client that is initiating the
connection request in an application-specific fashion. For example,
......@@ -129,11 +128,11 @@ SELECT rolname FROM pg_roles;
The set of database roles a given client connection can connect as
is determined by the client authentication setup, as explained in
<xref linkend="client-authentication">. (Thus, a client is not
necessarily limited to connect as the role with the same name as
limited to connect as the role matching
its operating system user, just as a person's login name
need not match her real name.) Since the role
identity determines the set of privileges available to a connected
client, it is important to carefully configure this when setting up
client, it is important to carefully configure privileges when setting up
a multiuser environment.
</para>
</sect1>
......@@ -152,7 +151,7 @@ SELECT rolname FROM pg_roles;
<para>
Only roles that have the <literal>LOGIN</> attribute can be used
as the initial role name for a database connection. A role with
the <literal>LOGIN</> attribute can be considered the same thing
the <literal>LOGIN</> attribute can be considered the same
as a <quote>database user</>. To create a role with login privilege,
use either:
<programlisting>
......@@ -204,7 +203,7 @@ CREATE USER <replaceable>name</replaceable>;
other roles, too, as well as grant or revoke membership in them.
However, to create, alter, drop, or change membership of a
superuser role, superuser status is required;
<literal>CREATEROLE</> is not sufficient for that.
<literal>CREATEROLE</> is insufficient for that.
</para>
</listitem>
</varlistentry>
......@@ -250,15 +249,15 @@ CREATE USER <replaceable>name</replaceable>;
want to disable index scans (hint: not a good idea) anytime you
connect, you can use:
<programlisting>
ALTER ROLE myname SET enable_indexscan TO off;
ALTER ROLE myname SET statement_timeout = '5min';
</programlisting>
This will save the setting (but not set it immediately). In
subsequent connections by this role it will appear as though
<literal>SET enable_indexscan TO off;</literal> had been executed
<literal>SET statement_timeout = '5min'</literal> had been executed
just before the session started.
You can still alter this setting during the session; it will only
be the default. To remove a role-specific default setting, use
<literal>ALTER ROLE <replaceable>rolename</> RESET <replaceable>varname</>;</literal>.
<literal>ALTER ROLE <replaceable>rolename</> RESET <replaceable>varname</></literal>.
Note that role-specific defaults attached to roles without
<literal>LOGIN</> privilege are fairly useless, since they will never
be invoked.
......@@ -381,15 +380,16 @@ REVOKE <replaceable>group_role</replaceable> FROM <replaceable>role1</replaceabl
</para>
<para>
The members of a role can use the privileges of the group role in two
The members of a group role can use the privileges of the role in two
ways. First, every member of a group can explicitly do
<xref linkend="sql-set-role" endterm="sql-set-role-title"> to
temporarily <quote>become</> the group role. In this state, the
database session has access to the privileges of the group role rather
than the original login role, and any database objects created are
considered owned by the group role not the login role. Second, member
roles that have the <literal>INHERIT</> attribute automatically have use of
privileges of roles they are members of. As an example, suppose we have
roles that have the <literal>INHERIT</> attribute automatically inherit the
privileges of roles of which they are members, including their
<literal>INHERIT</> attributes. As an example, suppose we have
done:
<programlisting>
CREATE ROLE joe LOGIN INHERIT;
......@@ -454,7 +454,7 @@ RESET ROLE;
special privileges, but they are never inherited as ordinary privileges
on database objects are. You must actually <command>SET ROLE</> to a
specific role having one of these attributes in order to make use of
the attribute. Continuing the above example, we might well choose to
the attribute. Continuing the above example, we might choose to
grant <literal>CREATEDB</> and <literal>CREATEROLE</> to the
<literal>admin</> role. Then a session connecting as role <literal>joe</>
would not have these privileges immediately, only after doing
......@@ -478,7 +478,7 @@ DROP ROLE <replaceable>name</replaceable>;
</sect1>
<sect1 id="perm-functions">
<title>Functions and Triggers</title>
<title>Function and Trigger Security</title>
<para>
Functions and triggers allow users to insert code into the backend
......
doc/src/sgml/wal.sgml
View file @ bf62b1a0
This diff is collapsed.
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment