On 10/21/2004 7:09 PM, Andrew Sullivan wrote:

> On Thu, Oct 21, 2004 at 05:55:12PM -0400, Chris Browne wrote:
>>  - As of 1.0.4, the slon replication engine refuses to work against
>>    any database that does not have the stored procedures for the same
>>    version loaded or where the shared object containing the C language
>>    support functions and the log trigger does not match the version
>>    number.  in a cluster must be upgraded at once.
> 
> As we saw on the list earlier this week, some people may regard this
> as a bug.  It sure seems to have been adopted with very little
> discussion on the list, and it strikes me as pretty odd that slony
> presents itself as a low-cost upgrade path for PostgreSQL sites, and
> then requires a total outage itself when upgrading.  At a reasonably
> high traffic site, you have to take an outage to replace the log
> trigger function.  Isn't there a slightly less draconian way of
> implementing this?

Unfortunately not. The problem is that the old shared objects and old 
stored procedures will not get replaced until reconnects to the database.

Picky as you are, you will notice that my suggested upgrade procedure 
does in fact do that (allow old and new versions of the .so to be loaded 
by different backends at the same time), because it didn't include steps 
to shutdown all client access. But what my procedure ensures is at least 
that different slon processes don't call mixed versions of stored 
procedures against possibly conflicting versions of Slony schemas.

I am not calling for a complete outage of operations. All I'm asking for 
is a replication stop and falling behind for a minute or so.


Jan

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