Le 28 janvier 2012 00:29, Jan Wieck <JanWieck at yahoo.com> a écrit :
> 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.

Not a bug, I am abusing the word, sorry.
Good explanations, thanks to you and Steve for that.

Btw, it is nice that an improvement can be done in 2.2, as noted
upthread the issue here is limited to 9.1: maybe related to SSI taking
more stack space or any other change in postgresql code. Slony ability
to workaround the changes of PostgreSQL internals and manage different
version of PostgreSQL is very nice combo that I am very happy to see
slony dev-team maintaining.

-- 
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation