Log Message:
-----------
Document the memory usage change made this week.

1.  Change FAQ to indicate the resolution in 1.2

2.  Add new parameters to slonconf.sgml

Modified Files:
--------------
    slony1-engine/doc/adminguide:
        faq.sgml (r1.47 -> r1.48)
        slonconf.sgml (r1.10 -> r1.11)

-------------- next part --------------
Index: slonconf.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/slonconf.sgml,v
retrieving revision 1.10
retrieving revision 1.11
diff -Ldoc/adminguide/slonconf.sgml -Ldoc/adminguide/slonconf.sgml -u -w -r1.10 -r1.11
--- doc/adminguide/slonconf.sgml
+++ doc/adminguide/slonconf.sgml
@@ -335,6 +335,48 @@
       </listitem>
     </varlistentry>
 
+    <varlistentry id="slon-config-max-rowsize" xreflabel="sync_max_rowsize">
+      <term><varname>sync_max_rowsize</varname>  (<type>integer</type>)</term>
+      <indexterm>
+        <primary><varname>sync_max_rowsize</varname> configuration parameter</primary>
+      </indexterm>
+      <listitem>
+        <para>Size above which an sl_log_?  row's
+        <envar>log_cmddata</envar> is considered large.  Up to 500
+        rows of this size are allowed in memory at once. Rows larger
+        than that count into the <envar>sync_max_largemem</envar>
+        space allocated and <function>free()</function>'ed on demand.
+        </para>
+
+	<para>The default value is 8192, meaning that your expected
+	memory consumption (for the LOG cursor) should not exceed 8MB.
+        </para>
+      </listitem>
+    </varlistentry>
+
+    <varlistentry id="slon-config-max-largemem" xreflabel="sync_max_largemem">
+      <term><varname>sync_max_largemem</varname>  (<type>integer</type>)</term>
+      <indexterm>
+        <primary><varname>sync_max_largemem</varname> configuration parameter</primary>
+      </indexterm>
+      <listitem>
+        <para>Maximum memory allocated for large rows, where
+        <envar>log_cmddata</envar> are larger than
+        <envar>sync_max_rowsize</envar>.  </para>
+
+	<para>Note that the algorithm reads rows until
+	<emphasis>after</emphasis> this value is exceeded.  Otherwise,
+	a tuple larger than this value would stall replication.  As a
+	result, don't assume that memory consumption will remain
+	smaller than this value.
+        </para>
+
+        <para> The default value is 5242880.</para>
+      </listitem>
+    </varlistentry>
+
+    
+
   </variablelist>
 </sect1>
 </article>
Index: faq.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/faq.sgml,v
retrieving revision 1.47
retrieving revision 1.48
diff -Ldoc/adminguide/faq.sgml -Ldoc/adminguide/faq.sgml -u -w -r1.47 -r1.48
--- doc/adminguide/faq.sgml
+++ doc/adminguide/faq.sgml
@@ -1731,10 +1731,34 @@
 default modification to make is to change the second definition of
 <envar> SLON_DATA_FETCH_SIZE </envar> from 10 to 1. </para> </answer>
 
-<answer><para> There are plans to change the behaviour of <xref
-linkend="slon"> to better adapt to the size of these queries for
-version 1.2, so at that point, this note will hopefully become
-obsolete. </para> </answer>
+<answer><para> In version 1.2, configuration values <xref
+linkend="slon-config-max-rowsize"> and <xref
+linkend="slon-config-max-largemem"> are associated with a new
+algorithm that changes the logic as follows.  Rather than fetching 100
+rows worth of data at a time:</para>
+
+<itemizedlist>
+
+<listitem><para> The <command>fetch from LOG</command> query will draw
+in 500 rows at a time where the size of the attributes does not exceed
+<xref linkend="slon-config-max-rowsize">.  With default values, this
+restricts this aspect of memory consumption to about 8MB.  </para>
+</listitem>
+
+<listitem><para> Tuples with larger attributes are loaded until
+aggregate size exceeds the parameter <xref
+linkend="slon-config-max-largemem">.  By default, this restricts
+consumption of this sort to about 5MB.  This value is not a strict
+upper bound; if you have a tuple with attributes 50MB in size, it
+forcibly <emphasis>must</emphasis> be loaded into memory.  There is no
+way around that.  But <xref linkend="slon"> at least won't be trying
+to load in 100 such records at a time, chewing up 10GB of memory by
+the time it's done.  </para> </listitem>
+</itemizedlist>
+
+<para> This should alleviate problems people have been experiencing
+when they sporadically have series' of very large tuples. </para>
+</answer>
 </qandaentry>
 </qandaset>