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

Modified Files:
	bestpractices.sgml faq.sgml slonik_ref.sgml startslons.sgml 
Log Message:
Mark Stosberg pointed out that the use of the term "COPY SET" was a bit
confusing as it is initiated, behind the scenes, by SUBSCRIBE SET, but
the docs are not explicit about this.  Corrected this...


Index: startslons.sgml
===================================================================
RCS file: /home/cvsd/slony1/slony1-engine/doc/adminguide/startslons.sgml,v
retrieving revision 1.19
retrieving revision 1.20
diff -C2 -d -r1.19 -r1.20
*** startslons.sgml	2 Aug 2006 18:34:59 -0000	1.19
--- startslons.sgml	14 Mar 2007 16:53:51 -0000	1.20
***************
*** 88,93 ****
  one point not preferable to run it whilst subscribing a very large
  replication set where it is expected to take many hours to do the
! initial <command>COPY SET</command>.  The problem that came up in that
! case was that it figured that since it hasn't done a
  <command>SYNC</command> in 2 hours, something was broken requiring
  restarting slon, thereby restarting the <command>COPY SET</command>
--- 88,94 ----
  one point not preferable to run it whilst subscribing a very large
  replication set where it is expected to take many hours to do the
! <command>COPY SET</command> (the main event that processes a
! <command>SUBSCRIBE SET</command> request).  The problem that came up
! in that case was that it figured that since it hasn't done a
  <command>SYNC</command> in 2 hours, something was broken requiring
  restarting slon, thereby restarting the <command>COPY SET</command>

Index: slonik_ref.sgml
===================================================================
RCS file: /home/cvsd/slony1/slony1-engine/doc/adminguide/slonik_ref.sgml,v
retrieving revision 1.66
retrieving revision 1.67
diff -C2 -d -r1.66 -r1.67
*** slonik_ref.sgml	30 Jan 2007 11:47:31 -0000	1.66
--- slonik_ref.sgml	14 Mar 2007 16:53:51 -0000	1.67
***************
*** 1934,1953 ****
      </para>
      
!     <para> If the tables on the subscriber are <emphasis>not</emphasis> empty, then
!      the <command>COPY SET</command> process winds up doing more work than should be
!      strictly necessary:</para>
       <itemizedlist>
        
!       <listitem><para> It deletes all <quote>old</quote> entries in
!       the table</para></listitem>
  
!       <listitem><para> Those old entries
! 	clutter up the table until it is next
! 	<command>VACUUM</command>ed <emphasis>after</emphasis> the
! 	subscription process is complete</para></listitem>
        
        <listitem><para> The indices for the table will contain entries
! 	for the old, deleted entries, which will slow the process of
! 	inserting new entries into the index.</para></listitem>
       </itemizedlist>
  
--- 1934,1959 ----
      </para>
      
!     <para> If the tables on the subscriber are
!     <emphasis>not</emphasis> empty, then the <command>COPY
!     SET</command> event (which is part of the subscription process)
!     may wind up doing more work than should be strictly
!     necessary:</para>
       <itemizedlist>
+ 
+       <listitem><para> It attempts to <command>TRUNCATE</command> the
+       table, which will be efficient. </para> </listitem>
        
!       <listitem><para> If that fails (a foreign key relationship might
!       prevent TRUNCATE from working), it uses
!       <command>DELETE</command> to delete all <quote>old</quote>
!       entries in the table</para></listitem>
  
!       <listitem><para> Those old entries clutter up the table until it
!       is next <command>VACUUM</command>ed <emphasis>after</emphasis>
!       the subscription process is complete</para></listitem>
        
        <listitem><para> The indices for the table will contain entries
!       for the old, deleted entries, which will slow the process of
!       inserting new entries into the index.</para></listitem>
       </itemizedlist>
  
***************
*** 1960,1971 ****
  
       <para> The <command>SUBSCRIBE SET</command> request will,
!      nonetheless, return fairly much immediately, even though the work
!      is merely <quote>in progress.</quote> If you need to set up
!      subscriptions for a set of cascading nodes, you will need to wait
!      for each subscriber to complete subscribing before submitting
!      requests for subscriptions that use that node as a provider.  If
!      you don't, it won't be a big deal: <command>slonik</command> will
!      check the node, discover that it is not yet an active provider
!      for the set, and report back:</para>
  
  <programlisting>
--- 1966,1978 ----
  
       <para> The <command>SUBSCRIBE SET</command> request will,
!      nonetheless, return fairly much immediately, even though the
!      work, being handled by the <command>COPY SET</command> event, is
!      still in progress.  If you need to set up subscriptions for a set
!      of cascading nodes, you will need to wait for each subscriber to
!      complete subscribing before submitting requests for subscriptions
!      that use that node as a provider.  If you don't, it won't be a
!      big deal: <command>slonik</command> will check the node, discover
!      that it is not yet an active provider for the set, and report
!      back:</para>
  
  <programlisting>

Index: bestpractices.sgml
===================================================================
RCS file: /home/cvsd/slony1/slony1-engine/doc/adminguide/bestpractices.sgml,v
retrieving revision 1.25
retrieving revision 1.26
diff -C2 -d -r1.25 -r1.26
*** bestpractices.sgml	1 Mar 2007 21:02:31 -0000	1.25
--- bestpractices.sgml	14 Mar 2007 16:53:51 -0000	1.26
***************
*** 378,382 ****
  <listitem><para> Lowering Authority </para>
  
! <para> Traditionally, it has been stated that <quote>&slony; needs to
  use superuser connections.</quote> It turns out that this is not
  entirely true, and and if there are particular concerns about
--- 378,382 ----
  <listitem><para> Lowering Authority </para>
  
! <para> Traditionally, it has been stated that <quote>&slony1; needs to
  use superuser connections.</quote> It turns out that this is not
  entirely true, and and if there are particular concerns about

Index: faq.sgml
===================================================================
RCS file: /home/cvsd/slony1/slony1-engine/doc/adminguide/faq.sgml,v
retrieving revision 1.68
retrieving revision 1.69
diff -C2 -d -r1.68 -r1.69
*** faq.sgml	2 Feb 2007 20:24:16 -0000	1.68
--- faq.sgml	14 Mar 2007 16:53:51 -0000	1.69
***************
*** 240,244 ****
  </screen></para></question>
  
- 
  <answer> <para> There is evidently some reasonably old outstanding
  transaction blocking &slony1; from processing the sync.  You might
--- 240,243 ----
***************
*** 1018,1022 ****
  
  <answer><para> Another would be to treat the node as having failed,
! and use the &slonik; command <xref linkend="stmtdropnode"> to drop the
  node, and recreate it.  If the database is heavily updated, it may
  well be cheaper to do this than it is to find a way to let it catch
--- 1017,1021 ----
  
  <answer><para> Another would be to treat the node as having failed,
! and use the &lslonik; command <xref linkend="stmtdropnode"> to drop the
  node, and recreate it.  If the database is heavily updated, it may
  well be cheaper to do this than it is to find a way to let it catch
***************
*** 1679,1685 ****
  index on the primary key, and leaves all indexes alone whilst using
  the &postgres; <command>COPY</command> command to load the data.
! Further hurting performane, the <command>COPY SET</command> event
! starts by deleting the contents of tables, which potentially leaves a
! lot of dead tuples
  </para>
  
--- 1678,1684 ----
  index on the primary key, and leaves all indexes alone whilst using
  the &postgres; <command>COPY</command> command to load the data.
! Further hurting performance, the <command>COPY SET</command> event (an
! event that the subscription process generates) starts by deleting the
! contents of tables, which leaves the table full of dead tuples.
  </para>