I seem to have forgotten our cluster specs:

Both machines:
Slony 1.0.5
Postgres 7.4.6
Linux 2.6.mumble
8gb RAM
Lots of 15k RPM disk, in a sensible RAID 0+1 configuration

Master:
4x2.4ghz Xeon

Slave:
4x1.4ghz Xeon

> I'm still suspicious of sl_confirm; try the query below; I'll bet  
> it'll show something being behind.

Sadly, this appears not to be the case:

tii=# select con_origin, con_received, max(con_seqno),  
max(con_timestamp), now() - max(con_timestamp) as age from sl_confirm  
group by con_origin, con_received order by age;
  con_origin | con_received |  max   |            max             |       
  age
------------+--------------+--------+---------------------------- 
+-----------------
           2 |            1 |   9105 | 2005-01-11 12:29:36.415893 |  
00:00:00.859428
           1 |            2 | 443539 | 2005-01-11 12:29:25.959708 |  
00:00:11.315613
(2 rows)

Our sl_log_1:

tii=# analyze verbose sl_log_1;
INFO:  analyzing "_tii.sl_log_1"
INFO:  "sl_log_1": 9496 pages, 3000 rows sampled, 192294 estimated  
total rows
ANALYZE
tii=# select count(*) from sl_log_1;
  count
--------
  392891
(1 row)

Nor, it seems, are we missing any listen paths:
tii=# select * from sl_node ;
  no_id | no_active | no_comment
-------+-----------+-------------
      1 | t         | Master node
      2 | t         | Slave node
(2 rows)

tii=# select * from sl_listen ;
  li_origin | li_provider | li_receiver
-----------+-------------+-------------
          2 |           2 |           1
          1 |           1 |           2
(2 rows)

I have to admit to a feeling of helplessness; I'm not sure even where  
to begin investigating why we have 400,000 rows in sl_log_1, nor how to  
ascertain if some of those rows have been orphaned.

Thanks in advance,
jfb

-- 
James Felix Black
Programmer, iParadigms LLC
(510) 287-9720 x 250