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

> On 02/05/2015 02:03 PM, Tory M Blue wrote:
>
>>
>>
>> On Thu, Feb 5, 2015 at 10:45 AM, Steve Singer <ssinger at ca.afilias.info
>> <mailto:ssinger at ca.afilias.info>> wrote:
>>
>>     On 02/05/2015 01:41 PM, Tory M Blue wrote:
>>
>>
>>
>>
>>
> Your looking for long running transactions not queries.
>
> What does this give you?
>
> select state,min(xact_start) from pg_stat_activity group by state ;
>

 state  |              min
--------+-------------------------------
 active | 2015-02-05 12:14:13.445753-08
 idle   |
(2 rows)


>
> and what is
> select txid_current_snapshot(


 txid_current_snapshot
-------------------------------
 460123733:460124165:460123733
(1 row)


I didn't see anything in the pg_stat table that was not a current job, or a
job that had been running for any length of time..

I went ahead and manually truncated sl_log_1 , the next log switch worked
just fine, and the following truncate of sl_log_2 worked automatically as
well. I think this has something to do with the size of the table, and the
fact that sync events were taking 5-9 seconds each. Maybe, the truncate was
being blocked based on those events? I did some checking and I felt secure
that all events in sl_log_1 were in fact sync'd/replicated. I can't tell
you what was locking that table however.

But as of right now I seem to be in a good state

I based the commands off this thread/site

http://venublog.com/2012/03/12/postgresql-slony-replication-lag-manual-log-tables-cleanup/

older version but since I was not doing a delete and following the truncate
that 2.2 uses, felt I was in okay shape to go behind the curtains and try
to shake slon loose.

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