On 11/13/13 09:42, bugzilla-daemon at main.slony.info wrote:
> http://www.slony.info/bugzilla/show_bug.cgi?id=324
>
>            Summary: slony 2.1.4 slon creating extremely long query
>            Product: Slony-I
>            Version: devel
>           Platform: PC
>         OS/Version: Linux
>             Status: NEW
>           Severity: critical
>           Priority: low
>          Component: slon
>         AssignedTo: slony1-bugs at lists.slony.info
>         ReportedBy: jeff at pgexperts.com
>                 CC: slony1-bugs at lists.slony.info
>    Estimated Hours: 0.0
>
>
> Seems as though this is a duplicate of bug #264, and that patch appears to be
> in 2.1.4, so I'm not sure why I'm still seeing this behavior.
>
> After an initial sync that takes about 8hrs, slon generates this extremely long
> query (that log line by itself is 107MB in size) that looks like:
>
> 2013-11-13 10:44:26 EST ERROR  remoteWorkerThread_2: "declare LOG cursor for
> select log_origin, log_txid, log_tableid, log_actionseq, log_cmdtype,
> octet_length(log_cmddata), case when octet_length(log_cmddata) <= 8192 then
> log_cmddata else null end from "_migration".sl_log_1 where log_origin = 2 and
> log_tableid in
> (7,9,23,24,38,39,42,47,48,53,57,74,75,86,97,116,120,128,129,130,136,137,143)
> and log_txid >= '6236982' and log_txid < '6236996' and
> "pg_catalog".txid_visible_in_snapshot(log_txid, '6236996:6236996:')  and ( 
> log_actionseq <> '5342437751'  and  log_actionseq <> '5342362294'  and 
> log_actionseq <> '5341832481'  and  log_actionseq <> '5342413870'  and 
> log_actionseq <> '5342418592'  and  log_actionseq <> '5342202064'  and 
> log_actionseq <> '5341939025'  and  log_actionseq <> '5341887545'  and 
> log_actionseq <> '5342114362'  and  log_actionseq <> '5342300971'  and 
> log_actionseq <> '5341759946'  and  log_actionseq <> '5342195755'  and 
> log_actionseq <> '5342198736'  and  log_actionseq <> '5342218415'  and 
> log_actionseq <> '5342188807'  and  log_actionseq <> '5342225657'  and 
> log_actionseq <> '5342434567'  and  log_actionseq <> '5342088216'  and 
> log_actionseq <> '5342293611'  and  log_actionseq <> '5341866011'  and  
>
> .....
>
> and  log_actionseq <> '5342342863' ) order by log_actionseq" PGRES_FATAL_ERROR
> ERROR:  stack depth limit exceeded
>
> max_stack_depth is 4MB on these systems, but even setting it to the max doesn't
> do the job.
>
> BTW, the versions in bugzilla only go up to 2.0, which is why this is filed
> under devel.
>

I think the issue was there were 22 million rows in sl_log_2 which were
actually older than the initial sync kickoff.  Not really sure why they hadn't
been cleaned up, but I'm going to try another initial sync after truncating
those tables.