On 1/24/2012 4:57 AM, Cédric Villemain wrote:
> Le 22 janvier 2012 17:16, Steve Singer<steve at ssinger.info>  a écrit :
>>  On Sun, 22 Jan 2012, Brian Fehrle wrote:
>>
>>>  Hi all,
>>>
>>>  PostgreSQL 9.1.2
>>>  Slony 2.1.0
>>
>>  Set max_stack_depth in your postgresql.conf to something higher.
>>
>>  sync_group_maxsize in your slon.conf to something low MIGHT help (ie 1 or 2)
>>  but I think the default in 2.1 is pretty low anyway (like 20).
>
> Immediate workaround is in fact to increase max_stack_depth ( but max
> it to (ulimit -s minus 1MB)
>
> but ... isn't it slony which should not use more than
> default_stack_size ? can't there be an underlining bug ?

Not a bug per se. Maybe something to improve in a future release.

That list of log_actionseq <> clauses only ever occurs on the first sync 
of a new SUBSCRIBE SET directly from the origin. The subscriber copies 
all the tables in some state in between two SYNC events. During the 
first SYNC after that, it needs to filter out all the log rows, that are 
already incorporated in that data, so it collects them and saves them in 
that set's sl_setsync row. These are all the actions that happened and 
committed in between the last SYNC event created on the origin and the 
copy_set operation starting.

If those are many thousands, then this is a mighty busy database or the 
slon on the origin maybe wasn't running for a while.

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.


Jan

-- 
Anyone who trades liberty for security deserves neither
liberty nor security. -- Benjamin Franklin