On 1/11/2007 12:24 AM, Adam Cassar wrote:
> Thanks for your excellent reply.

Excellent?

You got quite a remarkable pain tolerance!

I consider the oversight, that the corruptions done to the system 
catalog on slaves make a smooth upgrade of PostgreSQL a real PITA, 
rather embarrassing. That got nothing to do with excellence. I should 
have seen this from the very beginning, but I didn't realize this until 
about a year ago or so.


Jan

> 
> On Thu, 2007-01-11 at 00:18 -0500, Jan Wieck wrote:
>> On 1/10/2007 10:55 PM, Adam Cassar wrote:
>> > Hello,
>> > 
>> > We are currently running slony successfully in a mixed PG environment
>> > (v8 and v8.1).
>> > 
>> > With the release of PG v8.2 we want to upgrade all servers in our
>> > cluster to v8.2
>> > 
>> > I thought this would be quite simple - just dump and restore the db and
>> > everything should work....
>> 
>> That assumption was quite wrong. That is not the way how to upgrade a 
>> Slony cluster.
>> 
>> The database schema of your subscriber nodes (slaves) is in an 
>> inconsistent state from PostgreSQL's point of view. I am planning to get 
>> rid of this problem in the future, but it will be some time before it 
>> can be fixed. That means, that you cannot dump and restore a subscriber.
>> 
>> If you have the luxury to take an outage long enough to
>> 
>>      1.) uninstall slony completely
>>      2.) dump, upgrade PostgreSQL and restore the master
>>      3.) throw away and install new PostgreSQL version on all slaves
>>      4.) rebuild the entire slony cluster
>> 
>> do that.
>> 
>> Unfortunately not everyone has that luxury. If you are among those 
>> unfortunate people, here are the 12 pains of Christmas, Slony gave to you:
>> 
>>      1.) upgrade the cluster to the latest slony production release
>>      2.) Make your designated Backup node a leaf node
>>      3.) DROP that designated Backup node.
>>      4.) throw away and install new PostgreSQL version on that node.
>>      5.) STORE NODE for it and go through the full subscription process.
>>      6.) wait until it is completely in sync.
>>      7.) make it the only direct subscriber of the master, with all
>>          other nodes being cascaded from it (directly or sub-cascaded).
>>      8.) Switchover to the designated backup.
>>      9.) Drop the old master (which is now a subscriber).
>>     10.) Upgrade old master to an empty, new PostgreSQL version.
>>     11.) Subscribe it (again, wait until complete and cought up).
>>     12.) Switch back and reshape the cluster as needed.
>> 
>> The reason why this is so ugly and painfull is entirely that it is 
>> impossible to dump and restore a subscriber any way, that restores the 
>> system catalog into it's slony-corrupted state. That is why I am 
>> currently focused entirely on fixing that problem. Things would be a lot 
>> easier without that.
>> 
>> 
>> 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 #