updating minor upgrade instructions to reflect that slony server files are now versioned

and both versions can co-exist in the $libdir and $sharedir at the same time

diff --git a/doc/adminguide/slonyupgrade.sgml b/doc/adminguide/slonyupgrade.sgml
index 648ab08a2994b035dad5da8f9ea657d7e08979a2..934958ba9800657ff4324950b6ef8cafb4b44d5b 100644 (file)
--- a/doc/adminguide/slonyupgrade.sgml
+++ b/doc/adminguide/slonyupgrade.sgml
@@ -33,53 +33,12 @@ mismatch between component versions, the &lslon; will refuse to start
 up, which provides protection against corruption. </para>
 
 <para> You need to be sure that the C library containing SPI trigger
-functions has been copied into place in the &postgres; build.  There
-are multiple possible approaches to this:</para>
-
-<para> The trickiest part of this is ensuring that the C library
-containing SPI functions is copied into place in the &postgres; build;
-the easiest and safest way to handle this is to have two separate
-&postgres; builds, one for each &slony1; version, where the postmaster
-is shut down and then restarted against the <quote>new</quote> build;
-that approach requires a brief database outage on each node.</para>
-
-<para> While that approach has been found to be easier and safer,
-nothing prevents one from carefully copying &slony1; components for
-the new version into place to overwrite the old version as
-the <quote>install</quote> step.  That might <emphasis>not</emphasis>
-work on <trademark>Windows</trademark> if it locks library files that
-are in use. It is also important to make sure that any connections 
-to the database are restarted after the new binary is installed. </para>
-
-<variablelist>
-
-<varlistentry><term>Run <command>make install</command> to install new
-&slony1; components on top of the old</term>
-
-<listitem><para>If you build &slony1; on the same system on which it
-is to be deployed, and build from sources, overwriting the old with
-the new is as easy as <command>make install</command>.  There is no
-need to restart a database backend; just to stop &lslon; processes,
-run the <command>UPDATE FUNCTIONS</command> script, and start new
-&lslon; processes.</para>
-
-<para> Unfortunately, this approach requires having a build
-environment on the same host as the deployment.  That may not be
-consistent with efforts to use common &postgres; and &slony1; binaries
-across a set of nodes. </para>
-</listitem></varlistentry>
-
-<varlistentry><term>Create a new &postgres; and &slony1; build</term>
-
-<listitem><para>With this approach, the old &postgres; build with old
-&slony1; components persists after switching to a new &postgres; build
-with new &slony1; components. In order to switch to the new &slony1;
-build, you need to restart the
-&postgres; <command>postmaster</command>, therefore interrupting
-applications, in order to get it to be aware of the location of the
-new components. </para></listitem></varlistentry>
-
-</variablelist>
+functions and the slony SQL files that get installed into the share 
+directory are installed on your database server.  The slony version
+number will be part of these files so they can be installed on your
+database server before the upgrade and co-exist with the old version
+of &slony1;
+</para>
 
 <sect2><title>Upgrade from 2.1 to 2.2</title>