Tom Lane wrote: > > My objection here is basically that this proposal passed on the > assumption that it would be very nearly zero effort to make it happen. > We are now finding out that we have a fair amount of work to do if we > want autovac to not mess up the regression tests, and I think that has > to mean that the proposal goes back on the shelf until 8.3 development > starts. We are already overcommitted in terms of the stuff that was > submitted *before* feature freeze. >
Kicking out autovacuum as default is a disaster, it took far too long to get in the backend already (wasn't it planned for 8.0?). You discuss this on the base of the regression tests, which obviously run on installations that do _not_ represent standard recommended installations. It's required for ages now to have vacuum running regularly, using cron or so. The regression tests have to deal with that default situation, in one way or the other (which might well mean "this tables don't need vacuum" or "this instance doesn't need vacuum"). IMHO blaming autovacuum for the test failures reverses cause and effect. Missing vacuum was probably a reason for poor performance of many newbie pgsql installations (and I must admit that I missed installing the cron job myself from time to time, though I _knew_ it was needed). As Magnus already pointed out, all win32 installations have it on by default, to take them to the safe side. Disabling it for modules a "retail" user will never launch appears overreacting. I can positively acknowledge that disabling autovacuum with a pg_autovacuum row does work, I'm using it in production. Regards, Andreas ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
