Thanks, Steve, but I'm not feeling very cheery now..
 
1) The sl_log_1 table has xid's in the range of 260914376 or so… Now the master node is staying on 8.3 for the moment; so I guess we're ok until we move it over.. but then what? what are the implications if the sl_log_1 table has transactions with lower xids in it? can we avoid problems if we make sure all nodes are up to date before the migration of the master node (and hence sl_log_1 is empty?)

2) How do I get the 8.4 version of the slony stored functions installed on the node that's moving up from 8.3 to 9.0? Once I pg_upgrade the box, and recompile and install slony for 9.0, will an update_functions suffice?

Thanks,

Norman
On Sep 1, 2011, at 7:46 PM, Steve Singer wrote:

> On Thu, 1 Sep 2011, Norman Yamada wrote:
> 
>> As was discussed in a previous thread here, pg_upgrade complains that the following slony tables/columns can't be migrated from 8.3.x to 9.0.x:
> 
> Also read over http://bugs.slony.info/bugzilla/show_bug.cgi?id=234
> In addition to the issues you have discussed you will also have to make sure that the 64 bit version of the xid's post upgrade are newer than the 64 bit versions after.  You might not see this issue on a new test cluster, you would only see it on a cluster that has had the 32 bit xid wrap around at least once.
> 
> An upgrade from 8.3 to 9.0 also will require you to make sure that the 8.4 version of the slony stored functions are installed not the 8.3 one.
> 
> I have not tried upgrading a slony cluster with pg_upgrade, so there might be additional issues still.