Brian Wipf wrote:
> Okay, I shut down postmaster, recompiled and reinstalled Slony-I
> 1.2.1RC1 without a hitch. I brought back up postgres, tried to start
> slon and got the same error as below.
> I then performed an uninstall node for nodes 1 and 2, thereby removing
> the Slony-I schema altogether. I then reinitialized the Slony-I
> cluster and when I tried to start slon, I got the same error about the
> Slony-I schema version being 1.2.0.
>
> How do I replace the Slony-I libraries for PostgreSQL? Is this a
> problem with RC1?
Yes, see:
http://gborg.postgresql.org/pipermail/slony1-general/2006-November/005207.html

Resolution is rather easy:

http://gborg.postgresql.org/pipermail/slony1-general/2006-November/005209.html
>
> From the documentation:
> " The trickiest part of this is ensuring that the C library containing
> SPI functions is copied into place in the PostgreSQL build; the
> easiest and safest way to handle this is to have two separate
> PostgreSQL builds, one for each Slony-I version, where the postmaster
> is shut down and then restarted against the "new" build; that approach
> requires a brief database outage on each node.
>
> While that approach has been found to be easier and safer, nothing
> prevents one from carefully copying Slony-I components for the new
> version into place to overwrite the old version as the "install" step.
> That might not work on Windows? if it locks library files that are in
> use."
>
> How tricky is it? "...carefully copying Slony-I components for the new
> version into place to overwrite the old version as the "install"
> step". Can someone spell this out for me, please? I'm trying to get
> this running on SUSE Linux 10.1 and Mac OS X 10.4.8 Server. I'm having
> the identical problem with both of them.
I can't speak to Windows, notably because of its "more aggressive locking."

On Wednesday, I did a 1.1.6 to 1.2.1 upgrade on AIX, which involved the
following steps:

Preface:
 - I had built 1.1.6 against a particular PG source tree
 - I set up 1.2.1 to build against the very same source tree, so it
would install into the very same directories

My steps to do the upgrade:
 - Stop the old slons
 - Run "make install" against the Slony-I 1.2.1 build
 - Run slonik script to "upgrade functions();" against both nodes
 - Restart slons (where the binaries had been overwritten by the new
1.2.1 version)

With that approach ("just do 'make install'") to deployment, it was
really as simple as that.  No need to even restart the postmaster.

I wouldn't do things that way in production; we do named builds that
integrate PostgreSQL and Slony-I binaries.  In the "production" case,
I'd need to change a symlink, so that a link:
   /opt/dbs/pgsql81-instance  -->
/opt/dbs/pgsql81-AIX53-slony-1.1.5-2006-06-01
   is replaced with
   /opt/dbs/pgsql81-instance  -->
/opt/dbs/pgsql81-AIX53-slony-1.2.1-2006-11-15

In THAT case, I'd need to restart the postmaster in order for the
Slony-I 1.2.1 functions to get properly pointed at.  The issue there
isn't really about Slony-I; it's about our preferred "DB build hygiene."

On Windows, I would expect file locking to prevent you from doing a
"make install" without shutting down the database, so that what you'd
need to do would look more like our "hygienic keeping builds separate"
approach.

Does that help, I hope?