On 02/05/2015 01:19 PM, Tory M Blue wrote:
> 2015-02-05 09:53:29 PST clsdb postgres 10.13.200.232(54830) 51877
> 2015-02-05 09:53:29.976 PSTNOTICE:  Slony-I: log switch to sl_log_2
> complete - truncate sl_log_1
>
> 2015-02-05 10:01:34 PST clsdb postgres 10.13.200.231(46083) 42459
> 2015-02-05 10:01:34.481 PSTNOTICE:  Slony-I: could not lock sl_log_1 -
> sl_log_1 not truncated
>
> Sooo I have 13 million rows in sl_log_1 and from my checks of various
> tables things are replicated, but this table still has a lock and is not
> being truncated, These errors have been happening since 12:08 AM..
>
> my sl_log_2 table now has 8 million rows but I'm replicating and not
> adding a bunch of data. We did some massive deletes last nights,
> 20million was the last batch when things stopped seeming to switch and
> truncate.
>
> Soooo, questions. How can I verify sl_log_1 can be truncated (everything
> in it has been replicated) and how can I figure out what is locking, so
> that slony can't truncate?


Everything must be replicated the confirmation must make it back to the 
origin before a log can be truncated?

What does your sl_status on your origin show?

The most common reasons why log truncation hasn't happened are

1) Replication is behind
2) Confirmations aren't making it back to the origin
3) You have a long running transaction on the origin.  A log running 
transaction can prevent log switching from taking place even if that 
transaction doesn't actually change replicated tables.



>
> I'm not hurting, just stressing at this point
>
> Thanks
> tory
>
>
> _______________________________________________
> Slony1-general mailing list
> Slony1-general at lists.slony.info
> http://lists.slony.info/mailman/listinfo/slony1-general
>