From: Steve Singer <ssinger@ca.afilias.info>
Date: Fri, 19 Jul 2013 19:18:26 +0000 (-0400)
Subject: documentation changes to reflect incompatibilities between slony 2.1.x and 2.2.0
X-Git-Tag: REL_2_2_0_B5~10^2~2
X-Git-Url: http://git.postgresql.org/gitweb/static/gitweb.js?a=commitdiff_plain;h=dd54aab6ca9dcdc47b512944bec77ca97de3d678;p=slony1-engine.git

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 d0ec7b41..efbca12a 100644
--- 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 4bad80de..648ab08a 100644
--- 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>