More minor updates and copy-editing.

doc/src/sgml/charset.sgml

-<!-- $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

doc/src/sgml/maintenance.sgml

 <!--
-$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>

doc/src/sgml/manage-ag.sgml

 <!--
-$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>

doc/src/sgml/user-manag.sgml

 <!--
-$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>