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

Modified Files:
	bestpractices.sgml maintenance.sgml slonconf.sgml 
Log Message:
Indicate changes to slon policy resulting from the recent patch that allows
configuring slon to never DELETE from sl_log_? tables, but to rather solely
trim data via TRUNCATE.

Notably this includes:
- Documenting the new slon parameters
- Changing wordings in several places to indicate the behaviour change


Index: slonconf.sgml
===================================================================
RCS file: /home/cvsd/slony1/slony1-engine/doc/adminguide/slonconf.sgml,v
retrieving revision 1.18
retrieving revision 1.19
diff -C2 -d -r1.18 -r1.19
*** slonconf.sgml	27 Aug 2007 22:23:29 -0000	1.18
--- slonconf.sgml	2 Jan 2008 19:12:42 -0000	1.19
***************
*** 336,339 ****
--- 336,370 ----
        </listitem>
      </varlistentry>
+ 
+ 
+     <varlistentry id="slon-config-cleanup-interval" xreflabel="slon_config_cleanup_interval">
+       <term><varname>cleanup_interval</varname> (<type>interval</type>)</term>
+       <indexterm>
+         <primary><varname>cleanup_interval</varname> configuration parameter</primary>
+       </indexterm>
+       <listitem>
+         <para>
+           Controls how quickly old events are trimmed out.  That
+           subsequently controls when the data in the log tables,
+           <envar>sl_log_1</envar> and <envar>sl_log_2</envar>, get
+           trimmed out.  Default: '10 minutes'.
+         </para>
+       </listitem>
+     </varlistentry>
+ 
+     <varlistentry id="slon-config-cleanup-deletelogs" xreflabel="slon_conf_cleanup_deletelogs">
+       <term><varname>cleanup_deletelogs</varname> (<type>boolean</type>)</term>
+       <indexterm>
+         <primary><varname>cleanup_deletelogs</varname> configuration parameter</primary>
+       </indexterm>
+       <listitem>
+         <para>
+           Controls whether or not we use DELETE to trim old data from the log tables,
+           <envar>sl_log_1</envar> and <envar>sl_log_2</envar>.
+           Default: false
+         </para>
+       </listitem>
+     </varlistentry>
+ 
      <varlistentry id="slon-config-desired-sync-time" xreflabel="desired_sync_time">
        <term><varname>desired_sync_time</varname>  (<type>integer</type>)</term>

Index: maintenance.sgml
===================================================================
RCS file: /home/cvsd/slony1/slony1-engine/doc/adminguide/maintenance.sgml,v
retrieving revision 1.27
retrieving revision 1.28
diff -C2 -d -r1.27 -r1.28
*** maintenance.sgml	18 Apr 2007 15:28:16 -0000	1.27
--- maintenance.sgml	2 Jan 2008 19:12:42 -0000	1.28
***************
*** 12,16 ****
  <productname>Slony-I</productname> cluster's namespace, notably
  entries in <xref linkend="table.sl-log-1">, <xref
! linkend="table.sl-log-2"> (not yet used), and <xref
  linkend="table.sl-seqlog">.</para></listitem>
  
--- 12,16 ----
  <productname>Slony-I</productname> cluster's namespace, notably
  entries in <xref linkend="table.sl-log-1">, <xref
! linkend="table.sl-log-2">, and <xref
  linkend="table.sl-seqlog">.</para></listitem>
  
***************
*** 26,30 ****
  vacuuming of these tables.  Unfortunately, it has been quite possible
  for <application>pg_autovacuum</application> to not vacuum quite
! frequently enough, so you probably want to use the internal vacuums.
  Vacuuming &pglistener; <quote>too often</quote> isn't nearly as
  hazardous as not vacuuming it frequently enough.</para>
--- 26,30 ----
  vacuuming of these tables.  Unfortunately, it has been quite possible
  for <application>pg_autovacuum</application> to not vacuum quite
! frequently enough, so you may prefer to use the internal vacuums.
  Vacuuming &pglistener; <quote>too often</quote> isn't nearly as
  hazardous as not vacuuming it frequently enough.</para>
***************
*** 59,71 ****
  </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
--- 59,73 ----
  </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</quote> process which notices when tables are
! modified, thereby creating dead tuples, and vacuums those tables,
! <quote>on demand.</quote> 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

Index: bestpractices.sgml
===================================================================
RCS file: /home/cvsd/slony1/slony1-engine/doc/adminguide/bestpractices.sgml,v
retrieving revision 1.28
retrieving revision 1.29
diff -C2 -d -r1.28 -r1.29
*** bestpractices.sgml	18 Apr 2007 15:28:16 -0000	1.28
--- bestpractices.sgml	2 Jan 2008 19:12:42 -0000	1.29
***************
*** 614,620 ****
  the exact form that the index setup should take. </para> 
  
! <para> In 1.2, there is a process that runs automatically to add
! partial indexes by origin node number, which should be the optimal
! form for such an index to take.  </para>
  </listitem>
  
--- 614,620 ----
  the exact form that the index setup should take. </para> 
  
! <para> In 1.2 and later versions, there is a process that runs
! automatically to add partial indexes by origin node number, which
! should be the optimal form for such an index to take.  </para>
  </listitem>