On Tue, 2006-05-30 at 14:48 -0700, Wayne Conrad wrote:
> On Tue, May 30, 2006 at 05:26:53PM -0400, Rod Taylor wrote:
> > I run with 64MB of stack specifically for Slony.
> > 
> > It seems that with each set you want to replicate you get a duplication
> > of the restriction clauses for transaction boundaries, including the
> > large IN clause.
> > 
> > If you run with a large number of sets and fall significantly behind due
> > to a long running transaction, the stack size required can grow quite
> > quickly.
> > 
> > Try dropping, merging or unsubscribing from a few sets then rejoin to
> > them after it catches up again.
> 
> Rod,
> 
> Sorry for the double-reply.  Forgot to use "reply to all."  Again.
> 
> Thanks for the advice about stack size.
> 
> One postgres workaround for the stack size limit on "in" clauses is to
> insert the values into a temporary table and then do a join on that
> table (instead of doing an "in" clause with a gazillion values).
> Would it make sense for Slony to do that when there are a large number
> of values?

No. It would not. Temp tables and Slony will go together about as well
as NOTIFY and Slony did. Huge issues with high transaction rates, which
is where this structure would be most useful.

Any chance you could log the query in question and send a copy?

Also, the oldest and newest ev_timestamp value from <schema>.sl_event
could be useful (approx. transaction gap timeframe).

> I looked again at the scripts I used to setup slony.  I claim (but due
> to my inexperience with Slony, cannot prove) that I have just one set.
> That set has all of the tables and sequences from my database.  There
> are only two databases in the cluster.

        select * from <schema>.sl_set;

If you do only have a single set, then I would assume there is a bug
somewhere in Slony.

--