> > Exactly what "replication work" do you mean?  One table? All tables being copied?
> > In my situation I have 6500*5 + 100 tables to copy.  No way is that going to be
> > completed in 5 minutes no matter that the tables are small.  (And no
> > I did not design the schema :)
> 
> That isn't the initial COPY, for sure, because none of ours will
> finish the COPY in 5 mins, either.  I suspect Rod means that there is
> a time limit on how long a snapshot-application process runs.  It
> can't be 5 mins, though, or we'd run into this after the initial
> COPY.  Chris, can you shed more light on this one?

Not only that, but please note in my followup message it often happens
in the opposite direction of the data flow.

Node 4 subscribes to datasets on Node 1.

Node 1 will (once every two months) result in hundreds of connections to
Node 4.

I've seen this between DB machines connected to the same switch, so I
don't think it is network related.

But again, I have no idea what triggers it.

> > Are you saying slony won't handle databases of >100GB?  Or tables? 
> > If the database is larger than that, exactly what patches should be added 
> > for exactly what result?  For the most part I am doing production work and never apply 
> > patches not in the main release for obvious reasons.  If there are crucial 
> > ones, though, I need more details.
> 
> Rod sent some observations about group size (and a patch) to the list
> oh, about a month ago?

I think so, but it was really just to bring things back to the way they
were before that. The maximum group size has shifted between 100 to
10000 a couple of times.

--