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 reinstalled 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 thos sl_confirm without fearing
any replication problem ?
Should I post my problem elsewhere ? (Bug tracking, Hackers list)

Thanks again for the help =3D)

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