<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 5, 2015 at 10:45 AM, Steve Singer <span dir="ltr"><<a href="mailto:ssinger@ca.afilias.info" target="_blank">ssinger@ca.afilias.info</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">On 02/05/2015 01:41 PM, Tory M Blue wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
</blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
<br>
Everything must be replicated the confirmation must make it back to<br>
the origin before a log can be truncated?<br>
<br>
What does your sl_status on your origin show?<br>
<br>
The most common reasons why log truncation hasn't happened are<br>
<br>
1) Replication is behind<br>
2) Confirmations aren't making it back to the origin<br>
3) You have a long running transaction on the origin. A log running<br>
transaction can prevent log switching from taking place even if that<br>
transaction doesn't actually change replicated tables.<br>
<br>
<br>
<br>
<br>
I'm not hurting, just stressing at this point<br>
<br>
Thanks<br>
tory<br>
<br>
<br>
Thanks Steve<br>
<br>
st_origin | st_received | st_last_event | st_last_event_ts<br>
| st_last<br>
_received | st_last_received_ts | st_last_received_event_ts<br>
| st_l<br>
ag_num_events | st_lag_time<br>
-----------+-------------+----<u></u>-----------+------------------<u></u>-----------+--------<br>
----------+-------------------<u></u>------------+-----------------<u></u>--------------+-----<br>
--------------+---------------<u></u>--<br>
1 | 3 | <a href="tel:5003919991" value="+15003919991" target="_blank">5003919991</a> | 2015-02-05 10:39:51.6253-08<br>
| 5<br>
003919976 | 2015-02-05 10:39:38.031286-08 | 2015-02-05 10:39:35.615581-08 |<br>
15 | 00:00:16.763937<br>
1 | 2 | <a href="tel:5003919991" value="+15003919991" target="_blank">5003919991</a> | 2015-02-05 10:39:51.6253-08<br>
| 5<br>
003919865 | 2015-02-05 10:37:37.127661-08 | 2015-02-05 10:37:34.596838-08 |<br>
126 | 00:02:17.78268<br>
1 | 4 | <a href="tel:5003919991" value="+15003919991" target="_blank">5003919991</a> | 2015-02-05 10:39:51.6253-08<br>
| 5<br>
003919982 | 2015-02-05 10:39:43.971439-08 | 2015-02-05 10:39:42.618684-08 |<br>
9 | 00:00:09.760834<br>
(3 rows)<br>
<br>
Not sure what this means exactly, but again if we are fully replicated,<br>
that would tell me that we have syncs being replied to. Obviously we<br>
have new data coming in but it's just slowing growing sl_log_2, which<br>
can't switch to sl_log_1, because _log_1 has not been able to truncate.<br>
And this is after restarting slon (for grins!)<br>
</blockquote>
<br>
<br>
Based on that I'd say the most likely culprit is (3) since it doesn't appear to be case 1 or 2. Do you have any long running transactions on your origin?<br>
<br></blockquote><div><br></div><div>I'm looking and don't see any long running queries, obviously with such a large sl_log table now, updates are in the 5-9 second range</div><div><br></div><div>2015-02-05 10:50:58 PST clsdb postgres 10.13.200.242(45605) 39989 2015-02-05 10:50:58.522 PSTLOG: duration: 6350.246 ms statement: COPY ( select log_origin, log_txid,LOTS OF STUFF DELETED.<br><br>Also the below tells me unless 2.2 is totally different that everything in my log tables has been syncd and just needs to be deleted?<br><br> ev_origin | ev_seqno | txid_snapshot_xmin <br>-----------+------------+--------------------<br> 1 | <a href="tel:5003918695" value="+15003918695" target="_blank">5003918695</a> | 459837392<br> 2 | 5000984115 | 34125442<br> 3 | 5000016464 | 15773130<br> 4 | 5000878307 | 15901785<br>(4 rows)<br><br> Thanks Steve!<br></div><div><br></div><div>Tory</div></div></div></div>