I think I found the problem with the "runaway vacuum"...
Craig James wrote:
Every 60 minutes, a vacuum process starts on my master node. Since I am not running AutoVacuum at all, and have no cron jobs, that only leaves Slony ...
One of our maintenance applications that runs occasionally used a "truncate table ..." on one of the replicated tables. Since TRUNCATE can't be handled by Slony, this lead to a duplicate-key violation in the slave database, so replication had stopped for a couple weeks (I guess I should check the log files more regularly, Slony has worked well for a while so I got lazy...). That meant the queue of changes had built up to millions of rows... hence the long-running vacuum of the Slony schema. Mystery solved. To cure it, I had to drop the primary key constraint on the slave table until Slony caught up. Is there any way at all to block, trap, or otherwise prevent TRUNCATE of certain tables? This problem is solved for now, but who knows when some unsuspecting app developer who hasn't read the Slony manual in detail will make this same mistake again? Thanks, Craig _______________________________________________ Slony1-general mailing list [email protected] http://lists.slony.info/mailman/listinfo/slony1-general
