On Thu, Feb 5, 2015 at 10:33 AM, Steve Singer <ssinger at ca.afilias.info>
wrote:

> 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
>>
>>
Thanks Steve

 st_origin | st_received | st_last_event |      st_last_event_ts       |
st_last
_received |      st_last_received_ts      |   st_last_received_event_ts   |
st_l
ag_num_events |   st_lag_time
-----------+-------------+---------------+-----------------------------+--------
----------+-------------------------------+-------------------------------+-----
--------------+-----------------
         1 |           3 |    5003919991 | 2015-02-05 10:39:51.6253-08 |
    5
003919976 | 2015-02-05 10:39:38.031286-08 | 2015-02-05 10:39:35.615581-08 |

           15 | 00:00:16.763937
         1 |           2 |    5003919991 | 2015-02-05 10:39:51.6253-08 |
    5
003919865 | 2015-02-05 10:37:37.127661-08 | 2015-02-05 10:37:34.596838-08 |

          126 | 00:02:17.78268
         1 |           4 |    5003919991 | 2015-02-05 10:39:51.6253-08 |
    5
003919982 | 2015-02-05 10:39:43.971439-08 | 2015-02-05 10:39:42.618684-08 |

            9 | 00:00:09.760834
(3 rows)

Not sure what this means exactly, but again if we are fully replicated,
that would tell me that we have syncs being replied to.  Obviously we have
new data coming in but it's just slowing growing sl_log_2, which can't
switch to sl_log_1, because _log_1 has not been able to truncate. And this
is after restarting slon (for grins!)

Thanks!
Tory
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.slony.info/pipermail/slony1-general/attachments/20150205/d8cb96f5/attachment-0001.htm