On Wed, 2007-05-16 at 11:58 -0500, Don Barthel wrote:
> I have one subscriber, one master.
> 
> Running 'select * from sl_status;' on the master I see:
> 
> <<
>  st_origin | st_received | st_last_event |      st_last_event_ts
> | st_last_received |    st_last_received_ts    |
> st_last_received_event_ts  | st_lag_num_events |   st_lag_time
> -----------+-------------+---------------+----------------------------+------------------+---------------------------+-------
> ---------------------+-------------------+-----------------
>          1 |           2 |       1713287 | 2007-05-16 11:46:39.741258
> |          1708951 | 2007-05-16 11:45:30.50751 | 2007-05-16
> 06:37:55.004498 |              4336 | 05:08:45.916761
> >>
> 
> I.e.
> st_last_received_event_ts == '2007-05-16 06:37:55.004498' and
> st_lag_num_events == 4336 and
> st_lag_time == '05:08:45.916761' (5 hours?)
> 
> Slony is controlled from the subscriber. I have restarted slony from
> the subscriber (clumsily with 'kill' then 'slon.sh restart' because
> 'slon.sh stop' didn't seem to stop it).
> 
> Events are getting processed but very slowly such that st_lag_time is
> increasing.
> 
> Every night I update a field in 100,000 records and slony can't seem
> to quite catch up.
> 

Slony doesn't handle transactions that change a lot of data very well.
Slony uses the same mechanism to replicate a single-tuple INSERT as an
unqualified UPDATE on 100M records.

If you can break up transactions into smaller chunks that will improve
the lag time a lot.

However, 100K tuples isn't that much really, so maybe your problem comes
from somewhere else? Do your indexes fit in the shared buffers on the
subscriber?

Regards,
	Jeff Davis