summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorBruce Momjian2007-04-18 20:44:53 +0000
committerBruce Momjian2007-04-18 20:44:53 +0000
commit05cd021c3084327022955baa4746a2de0bcfbd42 (patch)
treef878f3c28db5b750b6f6a54266bd820de43a8f44
parentef23a77441b94d1e2fde3f359d2e49703c70c9ca (diff)
Remove tabs from SGML source files.
-rw-r--r--doc/src/sgml/maintenance.sgml22
1 files changed, 11 insertions, 11 deletions
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 2be11332c27..29a79dd5de0 100644
--- 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>