On 9/25/2006 5:25 PM, Andrew Hammond wrote:
> 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.

Since the schema already includes a function knowing the version of the 
Slony schema present in a database, backend functions, slon and slonik 
have a pretty simple way of detecting whether they are acting against 
what they expect or not. All three of them are under our full source 
control and all required is doing the right calls at the right time 
(which last I checked we do). Maybe we don't, but that's easy to fix.

Any Slony UPGRADE kinda thing should pretty WELL know about versions all 
the time, mishaps on that side would point into our direction, no?


Jan


> 
> 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.
> _______________________________________________
> Slony1-general mailing list
> Slony1-general at gborg.postgresql.org
> http://gborg.postgresql.org/mailman/listinfo/slony1-general


-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck at Yahoo.com #