> I just wondered if others had seen this with a largeish scale
> database with large rows.

Yup. I copped out and threw hardware at it after reporting numerous bugs
(some of which were fixed immediately) with older Slony instances. I
haven't had the time to fix the rest myself.

I've "solved" the following:
      * Long running transactions (anything over a couple of hours)
        mixed in with frequent and short transactions on other
        structures. Slony has a few high churn areas like pg_listener.
        Solution, allow Slony to run without use of LISTEN/NOTIFY.
        Really I think just disabling LISTEN is enough. Arguably this is
        a PostgreSQL problem but PostgreSQL has always had that problem
        so I consider it a Slony design flaw.
      * Many large tuples. Bloats memory requirements significantly
        unless you reduce the fetch amount. My solution was to compile
        it 64 bit (allows me to get past 32bit memory limits) and bump
        swap up to accommodate the bloat. Slony does not actively use
        the memory so swapping it out is usually fine.

--