Hi Niels,

On Tuesday 16 January 2007 15:59, Niels Breet wrote:
| > RPONLINE=# select * from "_RPO".sl_status;
| > ]-------------+---------------------------
| > st_origin                 | 1
| > st_received               | 3
| > st_last_event | 2018097
| > st_last_event_ts          | 2007-01-16 14:54:44.99581 st_last_received
| >
| > | 1525251
| >
| > st_last_received_ts       | 2006-12-30 09:46:15.781741
| > st_last_received_event_ts | 2006-12-30 09:46:15.774831 st_lag_num_events
| >
| > | 492846
| >
| > st_lag_time               | 17 days 05:08:29.448725 -[ RECORD 3
|
| A node with id = 3 lags 17 days behind the origin. While that node
| is lagging, all events are kept in the log.
|
| So you need to either let that node catch up or remove it from the
| cluster. When that is completed, the log will be cleaned after about
| 20 minutes.

yes, that's clear; what I don't know is what I can do to let the node catch
up with the rest. I suspect that somehow maybe a confirmation event got lost.
Node 3 seems to be up to date itself:

This is the master (node 1):
[pg81 at pgmaster:~] echo 'select count(1) from "_RPO".sl_event;' | psql 
RPONLINE -p5481
 count  
--------
 935314
(1 row)

This is from node 3:
[pg81 at pgmaster:~] echo 'select count(1) from "_RPO".sl_event;' | psql 
RPONLINE -p5481 -hpgdb2
 count 
-------
  1050
(1 row)

What I'd like to know is: is there anything (except rebuilding node 3) I can
do to get rid of the old events?

Ciao,
Thomas

-- 
Thomas Pundt <thomas.pundt at rp-online.de> ---- http://rp-online.de/ ----