Log Message:
-----------
Add in 7.2 notes based on Rod Taylor's comments

Modified Files:
--------------
    slony1-engine/doc/adminguide:
        faq.sgml (r1.36 -> r1.37)
        prerequisites.sgml (r1.15 -> r1.16)

-------------- next part --------------
Index: prerequisites.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/prerequisites.sgml,v
retrieving revision 1.15
retrieving revision 1.16
diff -Ldoc/adminguide/prerequisites.sgml -Ldoc/adminguide/prerequisites.sgml -u -w -r1.15 -r1.16
--- doc/adminguide/prerequisites.sgml
+++ doc/adminguide/prerequisites.sgml
@@ -17,8 +17,8 @@
 <quote>binary</quote> applications (<emphasis>e.g.</emphasis> - <xref
 linkend="slonik">, <xref linkend="slon">) do not run on
 <trademark>Windows</trademark>, but a <xref linkend="slon"> running on
-one of the Unix-like systems has no reason to have difficulty connect
-to a PostgreSQL instance running on
+one of the Unix-like systems has no reason to have difficulty
+connecting to a PostgreSQL instance running on
 <trademark>Windows</trademark>.</para>
 
 <para> It ought to be possible to port <xref linkend="slon"> and <xref
@@ -55,7 +55,12 @@
 <listitem><para> You also need a recent version of &postgres;
 <emphasis>source</emphasis>.  &slony1; depends on namespace support so
 you must have &postgres; version 7.3.3 or newer to be able to build
-and use &slony1;.  </para></listitem>
+and use &slony1;.  </para>
+
+<para> Earlier versions of &postgres; are <emphasis> not </emphasis>
+supported, but note that one user has <quote>hacked</quote> &slony1;
+to do a 7.2-to-7.4 upgrade; see <link linkend="v72upgrade"> &postgres;
+7.2 notes </link>. </para></listitem>
 
 <listitem><para> GNU packages may be included in the standard
 packaging for your operating system, or you may need to look for
Index: faq.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/faq.sgml,v
retrieving revision 1.36
retrieving revision 1.37
diff -Ldoc/adminguide/faq.sgml -Ldoc/adminguide/faq.sgml -u -w -r1.36 -r1.37
--- doc/adminguide/faq.sgml
+++ doc/adminguide/faq.sgml
@@ -1529,6 +1529,66 @@
 </answer>
 
 </qandaentry>
+
+<qandaentry id="v72upgrade">
+<question> <para> I have a &postgres; 7.2-based system that I
+<emphasis>really, really</emphasis> want to use &slony1; to help me
+upgrade it to 8.0.  What is involved in getting &slony1; to work for
+that?</para>
+</question>
+
+<answer> <para> Rod Taylor has reported the following...
+</para>
+
+<para> This is approximately what you need to do:</para>
+<itemizedlist>
+<listitem><para>Take the 7.3 templates and copy them to 7.2 -- or otherwise
+        hardcode the version your using to pick up the 7.3 templates </para></listitem>
+<listitem><para>Remove all traces of schemas from the code and sql templates. I
+        basically changed the "." to an "_". </para></listitem>
+<listitem><para> Bunch of work related to the XID datatype and functions. For
+        example, Slony creates CASTs for the xid to xxid and back -- but
+        7.2 cannot create new casts that way so you need to edit system
+        tables by hand. I recall creating an Operator Class and editing
+        several functions as well. </para></listitem>
+<listitem><para>sl_log_1 will have severe performance problems with any kind of
+        data volume. This required a number of index and query changes
+        to optimize for 7.2. 7.3 and above are quite a bit smarter in
+        terms of optimizations they can apply. </para></listitem>
+<listitem><para> Don't bother trying to make sequences work. Do them by hand
+        after the upgrade using pg_dump and grep. </para></listitem>
+</itemizedlist>
+<para> Of course, now that you have done all of the above, it's not compatible
+with standard Slony now. So you either need to implement 7.2 in a less
+hackish way, or you can also hack up slony to work without schemas on
+newer versions of PostgreSQL so they can talk to each other.
+</para>
+<para> Almost immediately after getting the DB upgraded from 7.2 to 7.4, we
+deinstalled the hacked up Slony (by hand for the most part), and started
+a migration from 7.4 to 7.4 on a different machine using the regular
+Slony. This was primarily to ensure we didn't keep our system catalogues
+which had been manually fiddled with.
+</para>
+
+<para> All that said, we upgraded a few hundred GB from 7.2 to 7.4
+with about 30 minutes actual downtime (versus 48 hours for a dump /
+restore cycle) and no data loss.
+</para>
+</answer>
+
+<answer> <para> That represents a sufficiently ugly set of
+<quote>hackery</quote> that the developers are exceedingly reluctant
+to let it anywhere near to the production code.  If someone were
+interested in <quote>productionizing</quote> this, it would probably
+make sense to do so based on the &slony1; 1.0 branch, with the express
+plan of <emphasis>not</emphasis> trying to keep much in the way of
+forwards compatibility or long term maintainability of replicas.
+</para>
+
+<para> You should only head down this road if you are sufficiently
+comfortable with &postgres; and &slony1; that you are prepared to hack
+pretty heavily with the code.  </para> </answer>
+</qandaentry>
 </qandaset>
 
 <!-- Keep this comment at the end of the file Local variables: