Jeff wrote:
> so a while ago I posted about pg_listener vs autovacuum, however it  
> seems sl_event is also nearly impossible to have vacuumed for me.    
> However since then another issue has come up: sl_event cannot be  
> autovacuumed.
> 
> As of earlier today the last successful autovac of sl_event on my  
> origin was in may (I'd run vacuum manually a few times between then  
> and now).
> 
> There is quite a lot of replication going on so it is pretty much  
> constantly busy. Looking at my logs "busy" is currently defined as  
> 30-40M rows across various tables replicated daily.    I'm not sure  
> there is much that can be done for slony 1.2  beyond scheduling some  
> manual vacuuming - would 2.x be less prone to these issues?

You don't say what version of postgresql your on or anything about your 
autovacuum settings.

Do you have autovacuum set to skip the slony tables?

If autovacuum is disabled slony is supposed to handle vacuuming the 
tables itself (this was the default behaviour with some versions of 
slony on some versions of postgresql).  You might want to try doing this 
to see if it helps.  (There is a function 'ShouldSlonyVacuumTable'  in 
the version specific .sql files under src/backend)

The question is why hasn't autovacuum been getting to the slony tables.

Off the top of my head some possible reasons might be

-You have had an old subscriber/node in your configuration that you are 
no longer replicating to.  This means that nothing is being deleted from 
sl_event so autovacuum sees no reason to vacuum it
-Your vacuum cost delay settings are such that it takes forever for 
autovacuum to finish vacuuming, older versions of postgresql only 
autovacuumed one table at a time.  autovacuum just hasn't been able to 
get to your slony tables until now
-You had autovacuum disabled on for the slony tables








> 
> [postgres at XXXX log]$  grep "Jul 13" pgsql.log | grep "automatic vacuum  
> of table \"XXXX._replication.sl_event\"" | wc
>      540    6480   59228  (this morning)
> [postgres at XXXX log]$  grep "Jul 12" pgsql.log | grep "automatic vacuum  
> of table \"XXXX._replication.sl_event\"" | wc
>     1438   17256  157726
> [postgres at XXXlog]$  grep "Jul 11" pgsql.log | grep "automatic vacuum  
> of table \"XXXX._replication.sl_event\"" | wc
>     1164   13968  127691
> 
> --
> Jeff Trout <jeff at jefftrout.com>
> http://www.stuarthamm.net/
> http://www.dellsmartexitin.com/
> 
> 
> 
> _______________________________________________
> Slony1-general mailing list
> Slony1-general at lists.slony.info
> http://lists.slony.info/mailman/listinfo/slony1-general


-- 
Steve Singer
Afilias Canada
Data Services Developer
416-673-1142