<html><body><div style="color:#000; background-color:#fff; font-family:times new roman, new york, times, serif;font-size:12pt"><div><div class="MsoPlainText">Hi Slony admins,<o:p></o:p></div>

<div class="MsoPlainText"><o:p>&nbsp;</o:p></div>

<div class="MsoPlainText">Here I have a problem for a Slony setup on a really loaded primary database.&nbsp;<o:p></o:p></div><div class="MsoPlainText" style="color: rgb(0, 0, 0); font-size: 16px; font-family: 'times new roman', 'new york', times, serif; background-color: transparent; font-style: normal;">I try to build the slony and got from time to time an error.</div><div class="MsoPlainText" style="color: rgb(0, 0, 0); font-size: 16px; font-family: 'times new roman', 'new york', times, serif; background-color: transparent; font-style: normal;">Maybe is related to the high load we have. I hope you can help.</div><div class="MsoPlainText" style="color: rgb(0, 0, 0); font-size: 16px; font-family: 'times new roman', 'new york', times, serif; background-color: transparent; font-style: normal;"><br></div><div class="MsoPlainText" style="color: rgb(0, 0, 0); font-size: 16px; font-family: 'times new roman', 'new york', times, serif; background-color:
 transparent; font-style: normal;"><br></div>

<div class="MsoPlainText"><o:p>&nbsp;</o:p></div>

<div class="MsoPlainText">PGRES_FATAL_ERROR ERROR:&nbsp;
stack depth limit exceeded<o:p></o:p></div>

<div class="MsoPlainText">HINT:&nbsp; Increase the
configuration parameter "max_stack_depth", after ensuring the
platform's stack depth limit is adequate.<o:p></o:p></div>

<div class="MsoPlainText"><o:p>&nbsp;</o:p></div>

<div class="MsoPlainText">The line before this error message in the slony logs has
~11MB worth of text consisting mainly in a long concatenation of:<o:p></o:p></div>

<div class="MsoPlainText"><o:p>&nbsp;</o:p></div>

<div class="MsoPlainText">... and&nbsp;
log_actionseq &lt;&gt; '...'<o:p></o:p></div>

<div class="MsoPlainText"><o:p>&nbsp;</o:p></div>

<div class="MsoPlainText">This data is also present in the sl_setsync table.<o:p></o:p></div>

<div class="MsoPlainText"><o:p>&nbsp;</o:p></div>

<div class="MsoPlainText">The problem happens immediately after the slave finishes
syncing the set, enables the subscription and tries to do the first sync.<o:p></o:p></div>

<div class="MsoPlainText"><o:p>&nbsp;</o:p></div>

<div class="MsoPlainText">I found a thread about it here:<o:p></o:p></div>

<div class="MsoPlainText"><o:p>&nbsp;</o:p></div>

<div class="MsoPlainText"><a href="http://old.nabble.com/Slave-can%27t-catch-up,-postgres-error-%25">http://old.nabble.com/Slave-can%27t-catch-up,-postgres-error-%</a><o:p></o:p></div>

<div class="MsoPlainText">27stack-depth-limit-exceeded%27-td33182661.html<o:p></o:p></div>

<div class="MsoPlainText"><o:p>&nbsp;</o:p></div>

<div class="MsoPlainText">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).<o:p></o:p></div>

<div class="MsoPlainText"><o:p>&nbsp;</o:p></div>

<div class="MsoPlainText">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...<o:p></o:p></div>

<div class="MsoPlainText"><o:p>&nbsp;</o:p></div>

<div class="MsoPlainText">What I already tried and didn't help:<o:p></o:p></div>

<div class="MsoPlainText"><o:p>&nbsp;</o:p></div>

<div class="MsoPlainText">&nbsp;* 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;<o:p></o:p></div>

<div class="MsoPlainText"><o:p>&nbsp;</o:p></div>

<div class="MsoPlainText">&nbsp;* decrease the
slon deamon's SYNC_CHECK_INTERVAL to 1 second;<o:p></o:p></div>

<div class="MsoPlainText"><o:p>&nbsp;</o:p></div>

<div class="MsoPlainText">With both those I still get the error regularly...<o:p></o:p></div>

<div class="MsoPlainText"><o:p>&nbsp;</o:p></div>

<div class="MsoPlainText">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 ?<o:p></o:p></div>

<div class="MsoPlainText"><o:p>&nbsp;</o:p></div>

<div class="MsoPlainText">Jan Wieck mentions in the thread cited above that the a
solution would<o:p></o:p></div>

<div class="MsoPlainText">be:<o:p></o:p></div>

<div class="MsoPlainText"><o:p>&nbsp;</o:p></div>

<div class="MsoPlainText">&lt;quote&gt;<o:p></o:p></div>

<div class="MsoPlainText">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.<o:p></o:p></div>

<div class="MsoPlainText">&lt;/quote&gt;<o:p></o:p></div>

<div class="MsoPlainText"><o:p>&nbsp;</o:p></div>

<div class="MsoPlainText">Was this already implemented in a newer release ?<o:p></o:p></div>

<div class="MsoPlainText"><o:p>&nbsp;</o:p></div>

<div class="MsoPlainText">If not I would like to work on it, including back-patch
for the 2.0.7 version we use...<o:p></o:p></div>

<div class="MsoPlainText"><o:p>&nbsp;</o:p></div>

<div class="MsoPlainText">I would appreciate any help/hints on how to approach this
!<o:p></o:p></div>

<div class="MsoPlainText"><o:p>&nbsp;</o:p></div>

<div class="MsoPlainText">Cheers,<o:p></o:p></div></div></div></body></html>