On 07/01/2014 08:24 PM, Soni M wrote:


What is
select last_value from sl_log_status (it is a sequence) on the master 
when you see those "NOTICE:  Slony-I: could not lock sl_log_2 - sl_log_2 
not truncated" messages?

The sl_log_status value SHOULD be controlling both which (if any) tables 
the cleanup thread tries to lock/truncate and which of the log tables 
slon selects from.  It should be doing it such a way that the cleanup 
thread will never try to lock a table that slon is going to select from. 
Of course, there could be a bug here.

Also you should be aware of bug 167 (
http://www.slony.info/bugzilla/show_bug.cgi?id=167) which exists in 
slony 2.0.x where if replication is behind (your sl_log tables grow 
large) then selecting from sl_log becomes a full table scan making 
replication very slow.  Bug 167 was fixed in 2.1







>
> Master : Ubuntu 10.04 LTS, Postgre 9.1.13, Slony 2.0.7 from Ubuntu Package
> Slave : Ubuntu 10.04 LTS, Postgres 9.1.13, Slony 2.0.7 seems build from
> source.
> DB size 1.5 TB, Master utilize relative high number of temp tables and
> relative High number of locks on busy time
>
> DB=# select mode, count(*) from pg_locks group by mode;
>             mode           | count
> --------------------------+--------
>   ExclusiveLock            |    112
>   RowShareLock             |     37
>   AccessExclusiveLock      | 208577
>   RowExclusiveLock         |  33087
>   ShareUpdateExclusiveLock |      5
>   ShareLock                |  54906
>   AccessShareLock          |  93607
> (7 rows)
> but the slave is relative low on load.
>
> this is the connection from slave that open from May 25th
> postgres 14090  0.1  1.1 4512644 230760 ?      Ss   May25  59:08
> postgres: slony_user dbname master_ip_address(58554) idle
>
> On slave, this connection seems always keep on idle status, but on
> master, this connection often in "<IDLE> in transaction" status for some
> minutes and hold lock on sl_log_2 while transaction are filling up sl_log_1.
>
> Such condition usually happen on server high load time, but on low load
> it sometimes happen, but not many and does not affect on replication lag.
>
> On Wed, Jul 2, 2014 at 12:37 AM, Steve Singer <ssinger at ca.afilias.info
> <mailto:ssinger at ca.afilias.info>> wrote:
>
>     On 06/30/2014 01:05 PM, Soni M wrote:
>
>         it seems a slony process that has <IDLE> in transaction for many
>         times.
>         the client address and the user are identical to slony slave.
>
>
>
>     Which version of slony are you on?
>
>
>
>
>
> --
> Regards,
>
> Soni Maula Harriz