We got everything upgraded and moved over (which Slony helped
significantly with) but have abandoned the thought of running a full
copy in master/slave mode after about 2 weeks of trying it. We found
that Slony was taking up easily 30% of the systems resources so we will
be sticking with our old method.

The biggest issue was the unbounded growth of sl_log_1 while pg_dump was
running. The slony log table would grow to easily contain over 30M dead
tuples sitting in it that couldn't be deleted because they were over
minxid.  A group size of 1000 could keep up (well, for some definitions
of keep up -- it was regularly 30 minutes behind), but used up a full
CPU (and another for pg_dump).

I'll give it another shot with 8.0.x (in spring/summer) if the PITR
mechanisms work out and can eliminate the pg_dump bottleneck. No,
dumping the backup instead was not feasible.

In the mean time, a few suggestions:
      * Don't run the standard delete/vacuum clean job unless the
        minimum xid has changed since the last time.
      * Watch process memory usage or give us a way of changing the
        number of slots used on the command line. If you get enough 5MB
        tuples through in a sync, you can run our of process memory
        space pretty easily on 32bit hardware (3GB on that machine at
        the time). It worked much better on 64bit hardware.

Thanks for your efforts! Slony did successfully cut our downtime for
upgrading from about 18 to 24 hours to about 5 minutes.

--