Update of /home/cvsd/slony1/slony1-engine/doc/adminguide
In directory main.slony.info:/tmp/cvs-serv4019

Modified Files:
	bestpractices.sgml maintenance.sgml 
Log Message:
Document how to make autovacuum not bother vacuum Slony-I-managed 
tables, per Richard Yen.


Index: maintenance.sgml
===================================================================
RCS file: /home/cvsd/slony1/slony1-engine/doc/adminguide/maintenance.sgml,v
retrieving revision 1.26
retrieving revision 1.27
diff -C2 -d -r1.26 -r1.27
*** maintenance.sgml	17 Apr 2007 21:58:47 -0000	1.26
--- maintenance.sgml	18 Apr 2007 15:28:16 -0000	1.27
***************
*** 59,62 ****
--- 59,113 ----
  </para>
  
+ <sect2 id="maintenance-autovac"> <title> Interaction with &postgres; autovacuum </title>
+ 
+ <indexterm><primary>autovacuum interaction</primary></indexterm>
+ 
+ <para> Recent versions of &postgres; support an <quote/autovacuum/
+ process which notices when tables are modified, thereby creating dead
+ tuples, and vacuums those tables, <quote/on demand./ It has been
+ observed that this can interact somewhat negatively with &slony1;'s
+ own  vacuuming policies on its own tables. </para>
+ 
+ <para> &slony1; requests vacuums on its tables immediately after
+ completing transactions that are expected to clean out old data, which
+ may be expected to be the ideal time to do so.  It appears as though
+ autovacuum may notice the changes a bit earlier, and attempts
+ vacuuming when transactions are not complete, rendering the work
+ pretty useless.  It seems preferable to configure autovacuum to avoid
+ vacuum &slony1;-managed configuration tables. </para>
+ 
+ <para> The following query (change the cluster name to match your
+ local configuration) will identify the tables that autovacuum should
+ be configured not to process: </para>
+ 
+ <programlisting>
+ mycluster=# select oid, relname from pg_class where relnamespace = (select oid from pg_namespace where nspname = '_' || 'MyCluster') and relhasindex;
+   oid  |   relname    
+ -------+--------------
+  17946 | sl_nodelock
+  17963 | sl_setsync
+  17994 | sl_trigger
+  17980 | sl_table
+  18003 | sl_sequence
+  17937 | sl_node
+  18034 | sl_listen
+  18017 | sl_path
+  18048 | sl_subscribe
+  17951 | sl_set
+  18062 | sl_event
+  18069 | sl_confirm
+  18074 | sl_seqlog
+  18078 | sl_log_1
+  18085 | sl_log_2
+ (15 rows)
+ </programlisting>
+ 
+ <para> The following query will populate
+ <envar>pg_catalog.pg_autovacuum</envar> with suitable configuration
+ information: <command> insert into pg_catalog.pg_autovacuum (vacrelid,
+ enabled) select oid, 'f' from pg_catalog.pg_class where relnamespace =
+ (select oid from pg_namespace where nspname = '_' || 'MyCluster') and
+ relhasindex; </command> </para>
+ 
  <sect2><title> Watchdogs: Keeping Slons Running</title>
  
***************
*** 89,92 ****
--- 140,144 ----
  <sect2 id="gensync"><title>Parallel to Watchdog: generate_syncs.sh</title>
  
+ <indexterm><primary>generate SYNCs</primary></indexterm>
  <para>A new script for &slony1; 1.1 is
  <application>generate_syncs.sh</application>, which addresses the following kind of
***************
*** 219,222 ****
--- 271,276 ----
  <sect2><title> Other Replication Tests </title>
  
+ <indexterm><primary>testing replication</primary></indexterm>
+ 
  <para> The methodology of the previous section is designed with a view
  to minimizing the cost of submitting replication test queries; on a
***************
*** 288,291 ****
--- 342,346 ----
  </sect2>
  <sect2><title>mkservice </title>
+ <indexterm><primary>mkservice for BSD </primary></indexterm>
  
  <sect3><title>slon-mkservice.sh</title>

Index: bestpractices.sgml
===================================================================
RCS file: /home/cvsd/slony1/slony1-engine/doc/adminguide/bestpractices.sgml,v
retrieving revision 1.27
retrieving revision 1.28
diff -C2 -d -r1.27 -r1.28
*** bestpractices.sgml	18 Apr 2007 15:03:51 -0000	1.27
--- bestpractices.sgml	18 Apr 2007 15:28:16 -0000	1.28
***************
*** 144,147 ****
--- 144,156 ----
  </listitem>
  
+ <listitem><para> If you are using the autovacuum process in recent
+ versions of &postgres;, you may wish to leave &slony1; tables out, as
+ &slony1; is a bit more intelligent about vacuuming when it is expected
+ to be conspicuously useful (<emphasis>e.g.</emphasis> - immediately
+ after purging old data) to do so than autovacuum can be. </para>
+ 
+ <para> See <xref linkend="maintenance-autovac"> for more
+ details. </para> </listitem>
+ 
  <listitem> <para> Running all of the &lslon; daemons on a central
  server for each network has proven preferable. </para>