|
|
|
|
@ -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> |
|
|
|
|
|