On Thu, 1 Sep 2011, Norman Yamada wrote:

> 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?)

This issue was discovered by someone who upgraded via pg_dump and ended up 
with rows in sl_log_1 that were preventing the cleanup thread from 
truncating sl_log_1 so there sl_log_2 grew to be pretty big because a log 
switch couldn't complete.

If both sl_log_1 and sl_log_2 are empty on all nodes when you shutdown for 
the upgrade then you *might* be okay (off the top of my head I don't see 
other things that would break, but I was surprised when I discovered most 
of the other issues mentioned). I would also let a SYNC be processed 
and confirmed by all nodes before you start adding in new rows to sl_log_1 
(I am not sure how the logic that selects the transactions that committed 
between two SYNC events would deal with the xid list in the SYNC event list 
travelling backwards).





> 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?

The slonik UPDATE FUNCTIONS command should install the correct version of 
the stored functions if you run it after the upgrade.

>
> Thanks,
>
> Norman