On Fri, April 4, 2008 2:32 pm, Henry wrote:
> They're repeatedly restarting and copying the same tables - and never
> completing.

To clarify, "never completing" is probably not accurate; it's just been
repeating the truncate/copy process repeatedly several times since the
initial replication started (and the first slave finished) nine days ago.

Question:  does updates of some of the tables on the origin during the
initial replication have a bearing on this?  One of the parent tables on
the master is regularly updated, but the other tables are not.

test_slony_state.pl reports that "pg_listener relpages high -
6460"..."Perhaps a long running transaction is preventing pg_listener from
being vacuumed out?"   Presumably this is just a side-effect of the
initial replication?  Anyway, I did a vacuum full analyze on pg_listener
on all the nodes since it couldn't hurt.  After that vacuum, the report
says "pg_listener reltuples high - 346307"... :-)))

Sorry guys, please forgive my ignorance.  I'm feeling my way through this.
 The last time I felt so ignorant was (I think) over a decade ago digging
in a filesystem with debugfs.  Fortunately this is a prototyping
cluster... my ignorance-o-meter needs to come down a bit before I use it
live (think software RAID, LVM, clustering, etc).  Anyway, this
replication cluster worked fine for months, then one of the nodes lagged
behind in a big way and my impatience cajoled me into taking the tactical
nuke option of restarting from scratch (now, the db is bigger, so
everything is slower).

I can provide more config detail if required (plus output from
test_slony_state.pl).

Thanks
Henry