documentation changes to reflect incompatibilities between slony 2.1.x and 2.2.0

diff --git a/doc/adminguide/slonik_ref.sgml b/doc/adminguide/slonik_ref.sgml
index d0ec7b419454151a33823e633970d7a8fa313122..efbca12a08173b128a4f9fd095903ca43bcc8df6 100644 (file)
--- a/doc/adminguide/slonik_ref.sgml
+++ b/doc/adminguide/slonik_ref.sgml
@@ -89,8 +89,8 @@
      following slonik code:</para>
      <programlisting>
      try {
-         execute script (set id = 1, filename = '/tmp/script1.sql', event node=1);
-         execute script (set id = 1, filename = '/tmp/script2.sql', event node=1);
+         execute script ( filename = '/tmp/script1.sql', event node=1);
+         execute script ( filename = '/tmp/script2.sql', event node=1);
      }
      </programlisting>
 

diff --git a/doc/adminguide/slonyupgrade.sgml b/doc/adminguide/slonyupgrade.sgml
index 4bad80de5f97fa823e51b96bfd3287c15b4e967e..648ab08a2994b035dad5da8f9ea657d7e08979a2 100644 (file)
--- a/doc/adminguide/slonyupgrade.sgml
+++ b/doc/adminguide/slonyupgrade.sgml
@@ -4,7 +4,7 @@
 <indexterm><primary>Upgrading between minor slony versions</primary></indexterm>
 <para> Minor &slony1; versions can be upgraded using the slonik <xref
 linkend="stmtupdatefunctions"> command.  This includes upgrades from
-2.1.x to a newer version 2.1.y version or from 2.0.x to 2.1.y. </para>
+2.2.x to a newer version 2.2.y version or from 2.0.x to 2.1.y. </para>
 <para> When upgrading &slony1;, the installation on all nodes in a
 cluster must be upgraded at once, using the &lslonik;
 command <xref linkend="stmtupdatefunctions">.</para>
@@ -108,6 +108,58 @@ linkend="stmtupdatefunctions"> against each node to upgrade to version 2.2  </pa
 </para>
 </sect2>
 
+
+<sect2>
+<title>Incompatibilities between 2.1 and 2.2</title>
+
+<indexterm><primary>incompatibilities between versions</primary></indexterm>
+<sect3><title>Slony Log Tables</title>
+<para>
+The format of the slony log tables sl_log_1 and sl_log_2 has changed.  The data to be 
+replicated is now stored in an array of of column names and values.  It was previously stored
+as the text that would make up the SQL command.
+</para>
+</sect3>
+
+<sect3><title>FAILOVER changes</title>
+<para>
+The syntax of the <xref linkend="stmtfailover"/> command has changed.  If multiple nodes
+in the cluster have failed, including subscriber-only nodes, then all failed nodes must be passed
+to the failover command.  The rules concerning which nodes can be a failover node have also
+changed.</para>
+</sect3>
+
+<sect3><title>Reshaping subscriptions</title>
+<para>
+Prior to slony 2.2.0 you could use the <xref linkend="stmtsubscribeset"/> command to change
+a subscribers provider to a different provider for a set.  As of &slony1; 2.2.0 the 
+<xref linkend="stmtsubscribeset"/> command can only be used to establish an initial subscription.
+The <xref linkend="stmtresubscribenode" /> command has been introduced to change the provider
+node.
+
+</para>
+</sect3>
+
+<sect3>
+<title>EXECUTE SCRIPT OPTIONS</title>
+<para>
+The <xref linkend="stmtddlscript"/> command no longer accepts SET ID as a valid option.
+</para>
+
+</sect3>
+
+<sect3>
+<title>LOG SHIPPING</title>
+<para>
+The format of the .SQL files generated for log shipping has changed. Prior to &slony1; 2.2.0 
+these files contained SQL INSERT/UPDATE/DELETE statements.  They now contain a COPY statement
+that inserts these changes into a sl_log_archive table.  A trigger will then apply these changes
+on the log shipping target.
+</para>
+</sect3>
+</sect2>
+
+
 <sect2>
 <title>Incompatibilities between 2.0 and 2.1</title>
 <indexterm><primary>incompatibilities between versions</primary></indexterm>