Put the disk information all in one chapter.

4 files changed, 46 insertions, 110 deletions

diff --git a/doc/src/sgml/admin.sgml b/doc/src/sgml/admin.sgml
index 75227bf1823..59174345063 100644
--- a/doc/src/sgml/admin.sgml
+++ b/doc/src/sgml/admin.sgml
@@ -1,5 +1,5 @@
 <!--
-$Header: /cvsroot/pgsql/doc/src/sgml/Attic/admin.sgml,v 1.38 2002/09/25 21:16:10 petere Exp $
+$Header: /cvsroot/pgsql/doc/src/sgml/Attic/admin.sgml,v 1.39 2002/10/16 22:06:33 petere Exp $
 -->
 
 <book id="admin">
@@ -34,7 +34,6 @@ $Header: /cvsroot/pgsql/doc/src/sgml/Attic/admin.sgml,v 1.38 2002/09/25 21:16:10
   &monitoring;
   &diskusage;
   &wal;
-  &recovery;
   &regress;
   &release;
 
diff --git a/doc/src/sgml/diskusage.sgml b/doc/src/sgml/diskusage.sgml
index d7e5cb27945..96507dd0935 100644
--- a/doc/src/sgml/diskusage.sgml
+++ b/doc/src/sgml/diskusage.sgml
@@ -1,12 +1,20 @@
 <!--
-$Header: /cvsroot/pgsql/doc/src/sgml/diskusage.sgml,v 1.5 2002/09/21 18:32:52 petere Exp $
+$Header: /cvsroot/pgsql/doc/src/sgml/diskusage.sgml,v 1.6 2002/10/16 22:06:33 petere Exp $
 -->
 
 <chapter id="diskusage">
  <title>Monitoring Disk Usage</title>
 
+ <para>
+  This chapter discusses how to monitor the disk usage of a PostgreSQL
+  database system.  In the current release, the database administrator
+  does not have much control over the on-disk storage layout, so this
+  chapter is mostly informative and can give you some ideas how to
+  manage the disk usage with operating system tools.
+ </para>
+
  <sect1 id="disk-usage">
-  <title>Monitoring Disk Usage</Title>
+  <title>Determining Disk Usage</Title>
 
   <indexterm zone="disk-usage">
    <primary>disk usage</primary>
@@ -96,6 +104,40 @@ play-# ORDER BY relpages DESC;
    shows disk usage for each database.
   </para>
  </sect1>
+
+ <sect1 id="disk-full">
+  <title>Disk Full Failure</title>
+
+  <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 may
+   result in subsequent corruption of database indexes, but not of the
+   fundamental data tables. If the WAL files are on the same disk (as
+   is the case for a default configuration) then a filled disk during
+   database initialization may result in corrupted or incomplete WAL
+   files. This failure condition is detected and the database server
+   will refuse to start up.
+  </para>
+
+  <para>
+   If you cannot free up additional space on the disk by deleting
+   other things you can move some of the database files to other file
+   systems and create a symlink from the original location.  But
+   note that <application>pg_dump</> cannot save the location layout
+   information of such a setup; a restore would put everything back in
+   one place.  To avoid running out of disk space, you can place the
+   WAL files or individual databases in other locations while creating
+   them.  See the <application>initdb</> documentation and <xref
+   linkend="manage-ag-alternate-locs"> for more information.
+  </para>
+
+  <tip>
+   <para>
+    Some file systems perform badly when they are almost full, so do
+    not wait until the disk is full to take action.
+   </para>
+  </tip>
+ </sect1>
 </chapter>
 
 <!-- Keep this comment at the end of the file
diff --git a/doc/src/sgml/filelist.sgml b/doc/src/sgml/filelist.sgml
index cbdd3bf5f18..5fd2325988f 100644
--- a/doc/src/sgml/filelist.sgml
+++ b/doc/src/sgml/filelist.sgml
@@ -1,4 +1,4 @@
-<!-- $Header: /cvsroot/pgsql/doc/src/sgml/filelist.sgml,v 1.23 2002/09/25 21:16:10 petere Exp $ -->
+<!-- $Header: /cvsroot/pgsql/doc/src/sgml/filelist.sgml,v 1.24 2002/10/16 22:06:33 petere Exp $ -->
 
 <!entity history    SYSTEM "history.sgml">
 <!entity info       SYSTEM "info.sgml">
@@ -49,7 +49,6 @@
 <!entity maintenance   SYSTEM "maintenance.sgml">
 <!entity manage-ag     SYSTEM "manage-ag.sgml">
 <!entity monitoring    SYSTEM "monitoring.sgml">
-<!entity recovery      SYSTEM "recovery.sgml">
 <!entity regress       SYSTEM "regress.sgml">
 <!entity release       SYSTEM "release.sgml">
 <!entity runtime       SYSTEM "runtime.sgml">
diff --git a/doc/src/sgml/recovery.sgml b/doc/src/sgml/recovery.sgml
deleted file mode 100644
index aa10b8cf640..00000000000
--- a/doc/src/sgml/recovery.sgml
+++ /dev/null
@@ -1,104 +0,0 @@
-<chapter Id="failure">
- <title>Database Failures</title>
-
- <para>
-  Database failures (or the possibility of such) must be assumed to be
-  lurking, ready to strike at some time in the future. A prudent
-  database administrator will plan for the inevitability of failures
-  of all possible kinds, and will have appropriate plans and
-  procedures in place <emphasis>before</emphasis> the failure occurs.
- </para>
-
- <para>
-  Database recovery is necessary in the event of hardware or software
-  failure. There are several categories of failures; some of these
-  require relatively minor adjustments to the database, while others
-  may depend on the existence of previously prepared database dumps
-  and other recovery data sets. It should be emphasized that if your
-  data is important and/or difficult to regenerate, then you should
-  have considered and prepared for various failure scenarios.
- </para>
-
- <sect1 id="failure-disk-full">
-  <title>Disk Filled</title>
-
-  <para>
-   A filled data disk may result in subsequent corruption of database
-   indexes, but not of the fundamental data tables. If the WAL files
-   are on the same disk (as is the case for a default configuration)
-   then a filled disk during database initialization may result in
-   corrupted or incomplete WAL files. This failure condition is
-   detected and the database will refuse to start up. You must free
-   up additional space on the disk (or move the WAL area to another
-   disk; see <xref linkend="wal-configuration">) and then restart the
-   <application>postmaster</application> to recover from this condition.
-  </para>
- </sect1>
-
- <sect1 id="failure-disk-failed">
-  <title>Disk Failed</title>
-
-  <para>
-   Failure of any disk (or of a logical storage device such as a RAID
-   subsystem) involved with an active database will require
-   that the database be recovered from a previously prepared database
-   dump. This dump must be prepared using
-   <application>pg_dumpall</application>, and updates to the database
-   occurring after the database installation was dumped will be lost. 
-  </para>
- </sect1>
-
-<!--
- <sect1>
-  <title>File Corrupted</title>
-
-  <para>
-  </para>
- </sect1>
-
- <sect1>
-  <title>Table Corrupted</title>
-
-  <para>
-  </para>
- </sect1>
-
- <sect1>
-  <title></title>
-
-  <para>
-  </para>
- </sect1>
-
- <sect1>
-  <title></title>
-
-  <para>
-  </para>
- </sect1>
-
- <sect1>
-  <title></title>
-
-  <para>
-  </para>
- </sect1>
--->
-
-</chapter>
-
-<!-- Keep this comment at the end of the file
-Local variables:
-mode:sgml
-sgml-omittag:nil
-sgml-shorttag:t
-sgml-minimize-attributes:nil
-sgml-always-quote-attributes:t
-sgml-indent-step:1
-sgml-indent-data:t
-sgml-parent-document: ("postgres.sgml" "set" "book" "chapter")
-sgml-default-dtd-file:"./reference.ced"
-sgml-exposed-tags:nil
-sgml-local-ecat-files:nil
-End:
--->