Well 
I've did a test preventing autvacuum vacuuming Slony's tables using
both master and slave 

 ALTER TABLE _mycluster.sl_nodelock SET (autovacuum_enabled=off);
 ALTER TABLE _mycluster.sl_setsync SET (autovacuum_enabled=off);
 ALTER TABLE _mycluster.sl_table SET (autovacuum_enabled=off);
 ALTER TABLE _mycluster.sl_sequence SET (autovacuum_enabled=off);
 ALTER TABLE _mycluster.sl_node SET (autovacuum_enabled=off);
 ALTER TABLE _mycluster.sl_listen SET (autovacuum_enabled=off);
 ALTER TABLE _mycluster.sl_path SET (autovacuum_enabled=off);
 ALTER TABLE _mycluster.sl_subscribe SET (autovacuum_enabled=off);
 ALTER TABLE _mycluster.sl_set SET (autovacuum_enabled=off);
 ALTER TABLE _mycluster.sl_event SET (autovacuum_enabled=off);
 ALTER TABLE _mycluster.sl_confirm SET (autovacuum_enabled=off);
 ALTER TABLE _mycluster.sl_seqlog SET (autovacuum_enabled=off);
 ALTER TABLE _mycluster.sl_registry SET (autovacuum_enabled=off);
 ALTER TABLE _mycluster.sl_seqlastvalue SET
(autovacuum_enabled=off);
 ALTER TABLE _mycluster.sl_config_lock SET (autovacuum_enabled=off);
 ALTER TABLE _mycluster.sl_archive_counter SET
(autovacuum_enabled=off);
 ALTER TABLE _mycluster.sl_status SET (autovacuum_enabled=off);
 ALTER TABLE _mycluster.sl_log_1 SET (autovacuum_enabled=off);
 ALTER TABLE _mycluster.sl_log_2 SET (autovacuum_enabled=off); 

and with vac_frequency = 3 (both on master and slave in slon
configuration file) 

As a consequence Slony, is doing the "vacuum analyze" himself 

Here is what I see on the log (slave) 

2011-09-21 13:18:24 CEST[11540] DEBUG1 cleanupThread: vacuum  analyze
"_mycluster".sl_archive_counter;
2011-09-21 13:18:24 CEST[11540] INFO   cleanupThread:    0.648
seconds for vacuuming
2011-09-21 13:50:59 CEST[11540] DEBUG1 cleanupThread: vacuum  analyze
"_mycluster".sl_event;
2011-09-21 13:50:59 CEST[11540] DEBUG1 cleanupThread: vacuum  analyze
"_mycluster".sl_confirm;
2011-09-21 13:50:59 CEST[11540] DEBUG1 cleanupThread: vacuum 
analyze
"_mycluster".sl_setsync;
2011-09-21 13:50:59 CEST[11540] DEBUG1 cleanupThread: vacuum  analyze
"_mycluster".sl_seqlog;
2011-09-21 13:51:00 CEST[11540] DEBUG1 cleanupThread: vacuum  analyze
"_mycluster".sl_archive_counter;
2011-09-21 13:51:00 CEST[11540] INFO   cleanupThread:    0.697
seconds for vacuuming 

So for vac_frequency = 3, this is the response to my question :) 

I will wait the end of the test to see if I've got a deadlock or not
:) 
On Wed, 21 Sep 2011 10:31:48 +0200, david.techer  wrote:
Hi 

I've begun to test Slony 2.0.7 a couple days ago. 
I've read the Slony documentation and see on the source for
clean_thread.c for vac_frequency 

However, I've got a question 

What happens if I put both on master and slave 

1) 

 ALTER TABLE _mycluster.sl_event SET (autovacuum_enabled=off);
 ALTER TABLE _mycluster.sl_confirm SET (autovacuum_enabled=off); 
2) vac_frequency=3 or vac_frequency=0 ? 

For your information, I use PostgreSQL 8.4, Slony 2.0.7. Autovacuum
is on
both master and slave. 
If I have understood, 

vac_frequency=0 implies that SLony will not used his "own"
maintenance operation and just do a analyze if required 
Let me know. 
-------------------------------------- Jean David TECHER davidgis.fr
-------------------------------------- 
-------------------------------------- Jean David TECHER davidgis.fr
-------------------------------------- 

   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.slony.info/pipermail/slony1-general/attachments/20110921/e7f667c9/attachment.htm