I had this problem a few weeks ago on 1.2.15.

It looked like  the failure was related to a COPY INTO command on a  
non replicated table that was hung.
I terminated this postgress backend but the log switch still didn't  
happen.

I restarted all the slony on each of the nodes and when I restarted  
the master the log switched correctly

Jason

On Aug 17, 2009, at 9:59 AM, Jaime Casanova wrote:

> On Mon, Aug 17, 2009 at 11:36 AM, Glyn  
> Astill<glynastill at yahoo.co.uk> wrote:
>> ----- Original Message ----
>>
>>> From: Jaime Casanova <jcasanov at systemguards.com.ec>
>>> To: slony1-general at lists.slony.info
>>> Sent: Monday, 17 August, 2009 16:35:01
>>> Subject: [slony1-general] switch from sl_log_1 to sl_log_2 never  
>>> ends
>>>
>>> Hi,
>>>
>>> For some reason the switch from sl_log_1 to sl_log_2 never ends,  
>>> if i
>>> execute logswitch_finish() i get this "NOTICE:  Slony-I: log  
>>> switch to
>>> sl_log_1 still in progress - sl_log_2 not truncated" and it  
>>> returns -1
>>> and if i execute logswitch_start() it says "ERROR:  Previous  
>>> logswitch
>>> still in progress"
>>>
>>> right now the sl_log_* tables have grown a lot
>>> relname  | n_live_tup
>>> -------------+--------------------
>>> sl_log_1 |  392275506
>>> sl_log_2 |   59708331
>>>
>>> this is a situation that has been like that for several days now.  
>>> this
>>> is slony 1.2.15...
>>>
>>
>>
>> Sorry to state the obvious, but have you checked for any open  
>> transactions that it might be waiting on?
>>
>
> i forgot to mention it no rows in "select * from pg_stat_activity
> where waiting;"
>
> and this query shows (as expected) different results every time i
> execute it, but one of those results just a minute ago was 0 rows, so
> there is nothing stronger than AccessShareLock hanging in there...
> """
> SELECT client_addr as "ip cliente",
>       pg_stat_activity.datname as "base datos",
>       case pg_class.relkind when 'r' then 'Tabla' when 'i' then
> 'Indice' when 'S' then 'Secuencia' end as "tipo relacion",
>       pg_class.relname as relacion,
>       pg_locks.mode as "modo bloqueo",
>       pg_locks.granted as "bloqueo concedido",
>       pg_stat_activity.usename as usuario,
>       pg_stat_activity.current_query as "consulta origen",
>       to_char(pg_stat_activity.query_start,'HH24:MI:SS') as "inicio
> consulta",
>       to_char(age(now(), pg_stat_activity.query_start),'HH24:MI:SS')
> as "edad consulta",
>       pg_stat_activity.procpid as "id proceso"
>  FROM pg_stat_activity,pg_locks LEFT OUTER JOIN pg_class ON
> (pg_locks.relation = pg_class.oid)
> WHERE pg_locks.pid=pg_stat_activity.procpid and
> pg_stat_activity.procpid <> pg_backend_pid()
>   and pg_locks.mode <> 'AccessShareLock'
> ORDER BY 5, 10 desc;
> """
>
> ideas?
>
> -- 
> Atentamente,
> Jaime Casanova
> Soporte y capacitación de PostgreSQL
> Asesoría y desarrollo de sistemas
> Guayaquil - Ecuador
> Cel. +59387171157
> _______________________________________________
> Slony1-general mailing list
> Slony1-general at lists.slony.info
> http://lists.slony.info/mailman/listinfo/slony1-general