More minor updates and copy-editing.

doc/src/sgml/diskusage.sgml

 <!--
-$PostgreSQL: pgsql/doc/src/sgml/diskusage.sgml,v 1.12 2004/12/01 19:00:27 tgl Exp $
+$PostgreSQL: pgsql/doc/src/sgml/diskusage.sgml,v 1.13 2004/12/28 19:08:58 tgl Exp $
 -->
 
 <chapter id="diskusage">
@@ -24,7 +24,10 @@ $PostgreSQL: pgsql/doc/src/sgml/diskusage.sgml,v 1.12 2004/12/01 19:00:27 tgl Ex
    which is used to store values too wide to fit comfortably in the main
    table.  There will be one index on the
    <acronym>TOAST</> table, if present. There may also be indexes associated
-   with the base table.
+   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
+   linkend="file-layout">.
   </para>
 
   <para>
@@ -135,6 +138,13 @@ SELECT relname, relpages FROM pg_class ORDER BY relpages DESC;
     not wait until the disk is completely full to take action.
    </para>
   </tip>
+
+  <para>
+   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.
+  </para>
  </sect1>
 </chapter>
 

doc/src/sgml/monitoring.sgml

 <!--
-$PostgreSQL: pgsql/doc/src/sgml/monitoring.sgml,v 1.26 2004/03/26 03:18:28 neilc Exp $
+$PostgreSQL: pgsql/doc/src/sgml/monitoring.sgml,v 1.27 2004/12/28 19:08:58 tgl Exp $
 -->
 
 <chapter id="monitoring">
@@ -26,7 +26,8 @@ $PostgreSQL: pgsql/doc/src/sgml/monitoring.sgml,v 1.26 2004/03/26 03:18:28 neilc
    analyzing performance.  Most of this chapter is devoted to describing
    <productname>PostgreSQL</productname>'s statistics collector,
    but one should not neglect regular Unix monitoring programs such as
-   <command>ps</> and <command>top</>.  Also, once one has identified a
+   <command>ps</>, <command>top</>, <command>iostat</>, and <command>vmstat</>.
+   Also, once one has identified a
    poorly-performing query, further investigation may be needed using
    <productname>PostgreSQL</productname>'s <xref linkend="sql-explain"
    endterm="sql-explain-title"> command.
@@ -172,25 +173,28 @@ postgres: <replaceable>user</> <replaceable>database</> <replaceable>host</> <re
   <title>Viewing Collected Statistics</Title>
 
   <para>
-   Several predefined views are available to show the results of
-   statistics collection, listed in <xref
-   linkend="monitoring-stats-views-table">.  Alternatively, one can
+   Several predefined views, listed in <xref
+   linkend="monitoring-stats-views-table">, are available to show the results
+   of statistics collection.  Alternatively, one can
    build custom views using the underlying statistics functions.
   </para>
 
   <para>
    When using the statistics to monitor current activity, it is important
    to realize that the information does not update instantaneously.
-   Each individual server process transmits new access counts to the collector
-   just before waiting for another client command; so a query still in
+   Each individual server process transmits new block and row access counts to
+   the collector just before going idle; so a query or transaction still in
    progress does not affect the displayed totals.  Also, the collector itself
-   emits new totals at most once per <varname>pgstat_stat_interval</varname> milliseconds
-   (500 by default).  So the displayed totals lag behind actual activity.
+   emits a new report at most once per <varname>pgstat_stat_interval</varname>
+   milliseconds (500 by default).  So the displayed information lags behind
+   actual activity.  Current-query information is reported to the collector
+   immediately, but is still subject to the
+   <varname>pgstat_stat_interval</varname> delay before it becomes visible.
   </para>
 
   <para>
    Another important point is that when a server process is asked to display
-   any of these statistics, it first fetches the most recent totals emitted by
+   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
@@ -614,7 +618,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS procpid,
    database administrator to view information about the outstanding
    locks in the lock manager. For example, this capability can be used
    to:
-	
+
    <itemizedlist>
     <listitem>
      <para>

doc/src/sgml/regress.sgml

-<!-- $PostgreSQL: pgsql/doc/src/sgml/regress.sgml,v 1.44 2004/12/03 17:46:19 tgl Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/regress.sgml,v 1.45 2004/12/28 19:08:58 tgl Exp $ -->
 
  <chapter id="regress">
   <title id="regress-title">Regression Tests</title>
@@ -15,16 +15,14 @@
    The regression tests are a comprehensive set of tests for the SQL
    implementation in <productname>PostgreSQL</productname>.  They test
    standard SQL operations as well as the extended capabilities of
-   <productname>PostgreSQL</productname>.  From
-   <productname>PostgreSQL</productname> 6.1 onward, the regression
-   tests are current for every official release.
+   <productname>PostgreSQL</productname>.
   </para>
 
   <sect1 id="regress-run">
    <title>Running the Tests</title>
 
   <para>
-   The regression test can be run against an already installed and
+   The regression tests can be run against an already installed and
    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
@@ -51,12 +49,13 @@ gmake check
 <screen>
 <computeroutput>
 ======================
- All 93 tests passed.
+ All 96 tests passed.
 ======================
 </computeroutput>
 </screen>
    or otherwise a note about which tests failed.  See <xref
-   linkend="regress-evaluation"> below for more.
+   linkend="regress-evaluation"> below before assuming that a
+   <quote>failure</> represents a serious problem.
   </para>
 
    <para>
@@ -130,10 +129,14 @@ gmake SHELL=/bin/ksh check
    server, <![%standalone-ignore;[as explained in <xref linkend="runtime">, ]]> then type
 <screen>
 gmake installcheck
+</screen>
+or for a parallel test
+<screen>
+gmake installcheck-parallel
 </screen>
    The tests will expect to contact the server at the local host and the
-   default port number, unless directed otherwise by <envar>PGHOST</envar> and <envar>PGPORT</envar>
-   environment variables.
+   default port number, unless directed otherwise by <envar>PGHOST</envar> and
+   <envar>PGPORT</envar> environment variables.
   </para>
   </sect1>
 
@@ -323,7 +326,7 @@ exclusion of those that don't.
 diff results/random.out expected/random.out
 </programlisting>
      should produce only one or a few lines of differences.  You need
-     not worry unless the random test repeatedly fails.
+     not worry unless the random test fails repeatedly.
     </para>
    </sect2>
   </sect1>