in sl_confirm with a seqno ~3277845 are preventing cleanupEvent() to
clean those.

And if I take a look at the seqno range on the master I get:

SELECT con_origin,
 MIN(con_seqno) AS first_con_seqno,
 MAX(con_seqno) AS last_con_seqno,
 MAX(con_seqno) - MIN(con_seqno) AS delta
FROM _ob2replication.sl_confirm
GROUP BY con_origin
ORDER BY con_origin ASC;

 con_origin | first_con_seqno | last_con_seqno |  delta
------------+-----------------+----------------+---------
         2 |         1850804 |        1850903 |      99
         5 |         1437305 |        1437403 |      98
        12 |          992789 |         992888 |      99
        16 |          957046 |         957145 |      99
        17 |          230040 |         230139 |      99
        21 |         1060965 |        3277845 | 2216880
        22 |         4790482 |        4790906 |     424
        23 |         1050820 |        1050919 |      99
        24 |           99661 |          99694 |      33
        25 |         1858636 |        1858734 |      98
        26 |         2629674 |        2629773 |      99
        27 |         1788901 |        1789000 |      99
(12 rows)

As you can see, the node 21 is keeping a huge range of confirmations
while the usual is to keep less than a thousand.

My supposition: Last year in september, there was a replication
maintenance, it is possible we might have to reinstall slony on the
node 21. If this was the case, the seqno was reset. But not every
event on the cluster was cleaned, and some confirm lines in sl_confirm
stayed there.

As every one of those confirm lines in sl_confirm in the cluster refer
to unexistent sl_event, can I delete those sl_confirm lines without fearing
any replication problem ?

Thanks again for the help =)

-- 
Laurent Raufaste
<http://www.glop.org/>