On 9/25/06, Niels Breet <postgres at breet.com> wrote:
> On Mon, September 25, 2006 20:30, Darcy Buskermolen wrote:
> > A few things about our installed files.
> >
> >
> > A) The more I've been thinking about this, the more I'm inclined to think
> > we should move the default install location for the *.sql functions.  I
> > think it might be worthwhile to mvoe them all into share/slony-I/
>
> Yes, separate location will also make it easier to clean up.
>
> > B) I've run into a situation where I want to run 2 diffrent versions of
> > slony (on 2 diffrent DB's) on the same cluster. While yes I can do it via
> > manipulation of the configure options, this  feels cumbersome.  What are
> > proples thoughts on expanding on the first item and, moving the files one
> >  level deeper, share/slony-I/1.3 , and going along with this, would it be
> >  worth while to do something simular the same thing with the .so's ?
>
> I think we should add the version to the .so's. So we have xxid.so.1.2.0
> etc.
>
> That way we can easily see what version a .so file is. And make it easier
> to run multiple versions within the same database.

I've been thinking about this for quite some time. As I see it, the
ultimate value of being able to have two working slony compiles linked
to the same postgres back-end is the potential for an online upgrade.
However, I think this would require versioning not only the library
file, but also of the functions. It may also demand versioned slony
schemas and other complications, I'm not sure.

The biggest problem I see with acheiving "online upgrade" is that any
upgrade would require an exclusive lock across all the tables in the
set to flip the functions. I don't see any ready solution to this
problem.

I can see some value in versioning the libraries simple to make it
self-documenting and obvious what version they are.