On 07/08/2014 11:06 AM, Soni M wrote:
> Sorry for late response,
> currently :
> NOTICE:  Slony-I: could not lock sl_log_1 - sl_log_1 not truncated
> dbname=# select last_value from sl_log_status;
>   last_value
> ------------
>            3
> (1 row)
>
> That's what it should be, right?
>
> But now, i see application transaction holding locks on sl_log_1, some
> select, insert and update transaction and also the <IDLE> in transaction
> just like before. But the row numbers of sl_log_1 not increasing anyway.
> The row num is increasing in sl_log_2. Is that normal?
>

Yes in log switch state 3 new rows get inserted into sl_log_2, and the 
slon tries to pull data from both tables.  When all the rows in sl_log_1 
have been replicated (and slon can get that exclusive lock) it truncates 
sl_log_1 and switches the log status to 1.


> The bug on 2.0.x as You said does happen in our environment, and it
> happens when the slave falls further behind the master. I should plan to
> move to 2.1 or 2.2.

I recommend 2.2


>
>
>
> On Wed, Jul 2, 2014 at 11:02 PM, Steve Singer <ssinger at ca.afilias.info
> <mailto:ssinger at ca.afilias.info>> wrote:
>
>     On 07/01/2014 08:24 PM, Soni M wrote:
>
>
>         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
>
>
>
>     I should also point out that slony 2.0.x does not properly support
>     PG 9.1 or higher.  You should use slony 2.1.x or 2.2.x with PG 9.1+.
>
>     If you are seeing a lot of transactions being aborted due to
>     serialization conflicts then this is because of the issues with PG
>     9.1 and slony 2.0 (though it doesn't sound like that is causing this
>     particular issue)
>
>
>
>         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>
>         <mailto: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
>
>
>
>
>
> --
> Regards,
>
> Soni Maula Harriz