Remove tabs from SGML source files.

diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 2be11332c272cd079ad798ad6cc8346210ac54c8..29a79dd5de0d02c8415ec8a849748e0343512ead 100644 (file)
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -1,4 +1,4 @@
-<!-- $PostgreSQL: pgsql/doc/src/sgml/maintenance.sgml,v 1.71 2007/04/16 18:29:50 alvherre Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/maintenance.sgml,v 1.72 2007/04/18 20:44:53 momjian Exp $ -->
 
 <chapter id="maintenance">
  <title>Routine Database Maintenance Tasks</title>
@@ -481,11 +481,11 @@ HINT:  Stop the postmaster and use a standalone backend to VACUUM in "mydb".
    </para>
 
    <para>
-       Beginning in <productname>PostgreSQL</productname> 8.3, autovacuum has a
-       multi-process architecture: there is a daemon process, called the
-       <firstterm>autovacuum launcher</firstterm>, which is in charge of starting
-       an <firstterm>autovacuum worker</firstterm> process on each database every
-       <xref linkend="guc-autovacuum-naptime"> seconds.
+    Beginning in <productname>PostgreSQL</productname> 8.3, autovacuum has a
+    multi-process architecture: there is a daemon process, called the
+    <firstterm>autovacuum launcher</firstterm>, which is in charge of starting
+    an <firstterm>autovacuum worker</firstterm> process on each database every
+    <xref linkend="guc-autovacuum-naptime"> seconds.
    </para>
 
    <para>
@@ -494,11 +494,11 @@ HINT:  Stop the postmaster and use a standalone backend to VACUUM in "mydb".
     and <command>ANALYZE</> work to do takes too long to run, the deadline may
     be failed to meet for other databases.  Also, if a particular database
     takes long to process, more than one worker may be processing it
-       simultaneously.  The workers are smart enough to avoid repeating work that
-       other workers have done, so this is normally not a problem.  Note that the
-       number of running workers does not count towards the <xref
-       linkend="guc-max-connections"> nor the <xref
-       linkend="guc-superuser-reserved-connections"> limits.
+    simultaneously.  The workers are smart enough to avoid repeating work that
+    other workers have done, so this is normally not a problem.  Note that the
+    number of running workers does not count towards the <xref
+    linkend="guc-max-connections"> nor the <xref
+    linkend="guc-superuser-reserved-connections"> limits.
    </para>
 
    <para>