Hi all,

We have here a slony setup where this error is consistently showing up:

PGRES_FATAL_ERROR ERROR:  stack depth limit exceeded
HINT:  Increase the configuration parameter "max_stack_depth", after
ensuring the platform's stack depth limit is adequate.

The line before this error message in the slony logs has ~11MB worth of
text consisting mainly in a long concatenation of:

... and  log_actionseq <> '...'

This data is also present in the sl_setsync table.

The problem happens immediately after the slave finishes syncing the
set, enables the subscription and tries to do the first sync.

I found a thread about it here:

http://old.nabble.com/Slave-can%27t-catch-up,-postgres-error-%
27stack-depth-limit-exceeded%27-td33182661.html

We're running on postgres 9.0.10 and slony1 version 2.0.7, and upgrading
is not an option in the near future (eventually we will upgrade both
postgres and slony).

The problem is that we hit this issue now more and more regularly - and
it is a killer for the slony replication, as it is not possible to
reliably set it up...

What I already tried and didn't help:

 * set max_stack_depth up to ridiculous amounts (10s of GB) - not sure
if I got the OS side of it right, but I did my best;

 * decrease the slon deamon's SYNC_CHECK_INTERVAL to 1 second;

With both those I still get the error regularly...

I wonder if this is fixed in newer slony releases, or if there's any
chance I can get some help/directions on how to fix/patch it in the
version we use to avoid this problem ?

Jan Wieck mentions in the thread cited above that the a solution would
be:

<quote>
The improvement for a future release would be to have the remote worker 
get the log_actionseq list at the beginning of copy_set. If that list is
longer than a configurable maximum, it would abort the subscribe and 
retry in a few seconds. It may take a couple of retries, but it should 
eventually hit a moment where a SYNC event was created recently enough 
so that there are only a few hundred log rows to ignore.
</quote>

Was this already implemented in a newer release ?

If not I would like to work on it, including back-patch for the 2.0.7
version we use...

I would appreciate any help/hints on how to approach this !

Cheers,
Csaba