More minor updates and copy-editing.

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>