mirrors/postgres
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

More minor updates and copy-editing.

Browse Source
This commit is contained in:
Tom Lane 2004-12-27 22:30:10 +00:00
parent 361f354109
commit 008e9e452f
4 changed files with 445 additions and 388 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

48
doc/src/sgml/charset.sgml
View File

@ -1,4 +1,4 @@
<!-- $PostgreSQL: pgsql/doc/src/sgml/charset.sgml,v 2.46 2004/11/15 06:32:13 neilc Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/charset.sgml,v 2.47 2004/12/27 22:30:10 tgl Exp $ -->
<chapter id="charset">
<title>Localization</>
@ -72,14 +72,15 @@ initdb --locale=sv_SE
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
system vendor and what was installed.
system vendor and what was installed. (On most systems, the command
<literal>locale -a</> will provide a list of available locales.)
</para>
<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.
aspect of the localization rules:
<informaltable>
<tgroup cols="2">
@ -90,7 +91,7 @@ initdb --locale=sv_SE
</row>
<row>
<entry><envar>LC_CTYPE</></>
<entry>Character classification (What is a letter? The upper-case equivalent?)</>
<entry>Character classification (What is a letter? Its upper-case equivalent?)</>
</row>
<row>
<entry><envar>LC_MESSAGES</></>
@ -154,7 +155,7 @@ initdb --locale=sv_SE
environment variables seen by the server, not by the environment
of any client. Therefore, be careful to configure the correct locale settings
before starting the server. A consequence of this is that if
client and server are set up to different locales, messages may
client and server are set up in different locales, messages may
appear in different languages depending on where they originated.
</para>
@ -181,7 +182,7 @@ initdb --locale=sv_SE
</note>
<para>
To enable messages translated to the user's preferred language,
To enable messages to be translated to the user's preferred language,
<acronym>NLS</acronym> must have been enabled at build time. This
choice is independent of the other locale support.
</para>
@ -234,8 +235,8 @@ initdb --locale=sv_SE
changed without repeating <command>initdb</>. Other locale
settings including <envar>LC_MESSAGES</> and <envar>LC_MONETARY</>
are initially determined by the environment the server is started
in. You can check the <envar>LC_COLLATE</> and <envar>LC_CTYPE</>
settings of a database using the <command>SHOW</> command.
in, but can be changed on-the-fly. You can check the active locale
settings using the <command>SHOW</> command.
</para>
<para>
@ -256,9 +257,9 @@ initdb --locale=sv_SE
Maintaining catalogs of message translations requires the on-going
efforts of many volunteers that want to see
<productname>PostgreSQL</> speak their preferred language well.
If messages in your language is currently not available or fully
If messages in your language are currently not available or not fully
translated, your assistance would be appreciated. If you want to
help, refer to the <xref linkend="nls"> or write to the developers'
help, refer to <xref linkend="nls"> or write to the developers'
mailing list.
</para>
</sect2>
@ -498,6 +499,31 @@ $ <userinput>psql -l</userinput>
(9 rows)
</screen>
</para>
<important>
<para>
Although you can specify any encoding you want for a database, it is
unwise to choose an encoding that is not what is expected by the locale
you have selected. The <literal>LC_COLLATE</literal> and
<literal>LC_CTYPE</literal> settings imply a particular encoding,
and locale-dependent operations (such as sorting) are likely to
misinterpret data that is in an incompatible encoding.
</para>
<para>
Since these locale settings are frozen by <command>initdb</>, the
apparent flexibility to use different encodings in different databases
of a cluster is more theoretical than real. It is likely that these
mechanisms will be revisited in future versions of
<productname>PostgreSQL</productname>.
</para>
<para>
One way to use multiple encodings safely is to set the locale to
<literal>C</> or <literal>POSIX</> during <command>initdb</>, thus
disabling any real locale awareness.
</para>
</important>
</sect2>
<sect2>
@ -805,7 +831,7 @@ RESET client_encoding;
<listitem>
<para>
Using <envar>PGCLIENTENCODING</envar>. If environment variable
Using <envar>PGCLIENTENCODING</envar>. If the environment variable
<envar>PGCLIENTENCODING</envar> is defined in the client's
environment, that client encoding is automatically selected
when a connection to the server is made. (This can

48
doc/src/sgml/maintenance.sgml
View File

@ -1,5 +1,5 @@
<!--
$PostgreSQL: pgsql/doc/src/sgml/maintenance.sgml,v 1.39 2004/12/13 18:05:08 petere Exp $
$PostgreSQL: pgsql/doc/src/sgml/maintenance.sgml,v 1.40 2004/12/27 22:30:10 tgl Exp $
-->
<chapter id="maintenance">
@ -79,7 +79,7 @@ $PostgreSQL: pgsql/doc/src/sgml/maintenance.sgml,v 1.39 2004/12/13 18:05:08 pete
Therefore, database administrators must understand these issues and
develop an appropriate maintenance strategy. This section concentrates
on explaining the high-level issues; for details about command syntax
and so on, see the <command>VACUUM</> command reference page.
and so on, see the <xref linkend="sql-vacuum"> reference page.
</para>
<para>
@ -91,6 +91,13 @@ $PostgreSQL: pgsql/doc/src/sgml/maintenance.sgml,v 1.39 2004/12/13 18:05:08 pete
times of day.
</para>
<para>
Beginning in <productname>PostgreSQL</productname> 8.0, there are
configuration parameters that can be adjusted to further reduce the
performance impact of background vacuuming. See
<xref linkend="runtime-config-resource-vacuum-cost">.
</para>
<sect2 id="vacuum-for-space-recovery">
<title>Recovering disk space</title>
@ -162,13 +169,20 @@ $PostgreSQL: pgsql/doc/src/sgml/maintenance.sgml,v 1.39 2004/12/13 18:05:08 pete
Recommended practice for most sites is to schedule a database-wide
<command>VACUUM</> once a day at a low-usage time of day,
supplemented by more frequent vacuuming of heavily-updated tables
if necessary. In fact, some installations with an extremely high
rate of data modification <command>VACUUM</command> some tables as
often as once very five minutes. (If you have multiple databases
if necessary. (Some installations with an extremely high
rate of data modification <command>VACUUM</command> busy tables as
often as once every few minutes.) If you have multiple databases
in a cluster, don't forget to <command>VACUUM</command> each one;
the program <filename>vacuumdb</> may be helpful.)
the program <filename>vacuumdb</> may be helpful.
</para>
<tip>
<para>
The <filename>contrib/pg_autovacuum</> program can be useful for
automating high-frequency vacuuming operations.
</para>
</tip>
<para>
<command>VACUUM FULL</> is recommended for cases where you know
you have deleted the majority of rows in a table, so that the
@ -404,6 +418,18 @@ VACUUM
you to ensure that such databases are frozen correctly.
</para>
<warning>
<para>
To be sure of safety against transaction wraparound, it is necessary
to vacuum <emphasis>every</> table, including system catalogs, in
<emphasis>every</> database at least once every billion transactions.
We have seen data loss situations caused by people deciding that they
only needed to vacuum their active user tables, rather than issuing
database-wide vacuum commands. That will appear to work fine ...
for a while.
</para>
</warning>
</sect2>
</sect1>
@ -475,7 +501,7 @@ VACUUM
If you start the server with
<command>pg_ctl</>, then <systemitem>stderr</>
is already redirected to <systemitem>stdout</>, so you just need a
pipe command:
pipe command, for example:
<programlisting>
pg_ctl start | rotatelogs /var/log/pgsql_log 86400
@ -499,7 +525,7 @@ pg_ctl start | rotatelogs /var/log/pgsql_log 86400
<para>
On many systems, however, <application>syslog</> is not very reliable,
particularly with large log messages; it may truncate or drop messages
just when you need them the most. Also, on <productname>linux</>,
just when you need them the most. Also, on <productname>Linux</>,
<application>syslog</> will sync each message to disk, yielding poor
performance. (You can use a <literal>-</> at the start of the file name
in the <application>syslog</> configuration file to disable this behavior.)
@ -508,8 +534,10 @@ pg_ctl start | rotatelogs /var/log/pgsql_log 86400
<para>
Note that all the solutions described above take care of starting new
log files at configurable intervals, but they do not handle deletion
of old, no-longer-interesting log files. You will also want to set
up a batch job to periodically delete old log files.
of old, no-longer-interesting log files. You will probably want to set
up a batch job to periodically delete old log files. Another possibility
is to configure the rotation program so that old log files are overwritten
cyclically.
</para>
</sect1>
</chapter>

31
doc/src/sgml/manage-ag.sgml
View File

@ -1,5 +1,5 @@
<!--
$PostgreSQL: pgsql/doc/src/sgml/manage-ag.sgml,v 2.38 2004/12/13 18:05:08 petere Exp $
$PostgreSQL: pgsql/doc/src/sgml/manage-ag.sgml,v 2.39 2004/12/27 22:30:10 tgl Exp $
-->
<chapter id="managing-databases">
@ -37,23 +37,21 @@ $PostgreSQL: pgsql/doc/src/sgml/manage-ag.sgml,v 2.38 2004/12/13 18:05:08 petere
</para>
<para>
An application that connects to the database server specifies in
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.) It is
possible, however, to access more than one schema from the same
connection. Schemas are a purely logical structure and who can
access what is managed by the privilege system. Databases are
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 databases but possibly
into separate schemas. More information about managing schemas is
in <xref linkend="ddl-schemas">.
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">.
</para>
<note>
@ -116,7 +114,7 @@ CREATE DATABASE <replaceable>name</>;
</para>
<para>
As an extra convenience, there is also a program that you can
As a convenience, there is a program that you can
execute from the shell to create new databases,
<command>createdb</>.<indexterm><primary>createdb</></>
@ -127,7 +125,7 @@ createdb <replaceable class="parameter">dbname</replaceable>
<command>createdb</> does no magic. It connects to the <literal>template1</>
database and issues the <command>CREATE DATABASE</> command,
exactly as described above.
The reference page on <command>createdb</> contains the invocation
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 may or may not be what
you want.
@ -285,10 +283,11 @@ createdb -T template0 <replaceable>dbname</>
<programlisting>
ALTER DATABASE mydb SET geqo TO off;
</programlisting>
This will save the setting (but not set it immediately) and in
subsequent connections it will appear as though <literal>SET geqo
TO off;</literal> had been called right before the session started.
Note that users can still alter this setting during the session; it
This will save the setting (but not set it immediately). In
subsequent connections to this database it will appear as though
<literal>SET geqo TO off;</literal> had been executed just before the
session started.
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>.
@ -322,7 +321,7 @@ DROP DATABASE <replaceable>name</>;
<para>
For convenience, there is also a shell program to drop
databases:<indexterm><primary>dropdb</></>
databases, <xref linkend="app-dropdb">:<indexterm><primary>dropdb</></>
<synopsis>
dropdb <replaceable class="parameter">dbname</replaceable>
</synopsis>

28
doc/src/sgml/user-manag.sgml
View File

@ -1,5 +1,5 @@
<!--
$PostgreSQL: pgsql/doc/src/sgml/user-manag.sgml,v 1.25 2004/02/17 09:07:16 neilc Exp $
$PostgreSQL: pgsql/doc/src/sgml/user-manag.sgml,v 1.26 2004/12/27 22:30:10 tgl Exp $
-->
<chapter id="user-manag">
@ -175,9 +175,10 @@ dropuser <replaceable>name</replaceable>
<programlisting>
ALTER USER myname SET enable_indexscan TO off;
</programlisting>
This will save the setting (but not set it immediately) and in
subsequent connections it will appear as though <literal>SET enable_indexscan
TO off;</literal> had been called right before the session started.
This will save the setting (but not set it immediately). In
subsequent connections by this user it will appear as though
<literal>SET enable_indexscan TO off;</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 undo any such setting, use <literal>ALTER USER
<replaceable>username</> RESET <replaceable>varname</>;</literal>.
@ -243,7 +244,7 @@ ALTER GROUP <replaceable>name</replaceable> DROP USER <replaceable>uname1</repla
<literal>RULE</>, <literal>REFERENCES</>, <literal>TRIGGER</>,
<literal>CREATE</>, <literal>TEMPORARY</>, <literal>EXECUTE</>,
<literal>USAGE</>, and <literal>ALL PRIVILEGES</>. For more
information on the different types of privileges support by
information on the different types of privileges supported by
<productname>PostgreSQL</productname>, see the
<xref linkend="sql-grant" endterm="sql-grant-title"> reference page.
The right to modify or
@ -289,18 +290,21 @@ REVOKE ALL ON accounts FROM PUBLIC;
Functions and triggers allow users to insert code into the backend
server that other users may execute without knowing it. Hence, both
mechanisms permit users to <quote>Trojan horse</quote>
others with relative impunity. The only real protection is tight
others with relative ease. The only real protection is tight
control over who can define functions.
</para>
<para>
Functions written in any language except SQL run inside the backend
server process with the operating systems permissions of the
database server daemon process. It is possible to change the
server's internal data structures from inside of trusted functions.
Functions run inside the backend
server process with the operating system permissions of the
database server daemon. If the programmming language
used for the function allows unchecked memory accesses, it is
possible to change the server's internal data structures.
Hence, among many other things, such functions can circumvent any
system access controls. This is an inherent problem with
user-defined C functions.
system access controls. Function languages that allow such access
are considered <quote>untrusted</>, and
<productname>PostgreSQL</productname> allows only superusers to
create functions written in those languages.
</para>
</sect1>