Peter Geoghegan <pg@bowt.ie> writes:
> My guess is that there are more things like that. Possibly even things
> that were never directly considered. VACUUM evolved in a world where
> we absolutely took not running in a transaction for granted. Changing
> that now is a pretty big deal. Maybe it would all be worth it if the end
> result was a super compelling feature. But I for one don't think that
> it will be.
Yeah. To be blunt, this proposal scares the sh*t out of me. I agree
that there are tons of subtle dependencies on our current assumptions
about how VACUUM works, and I strongly suspect that we won't find all of
them until after users have lost data. I cannot believe that running
VACUUM inside transactions is valuable enough to take that risk ...
especially if it's a modified limited kind of VACUUM that doesn't
eliminate the need for periodic real VACUUMs.
In general, I do not believe in encouraging users to run VACUUM
manually in the first place. We would be far better served by
spending our effort to improve autovacuum's shortcomings. I'd
like to see some sort of direct attack on its inability to deal
with temp tables, for instance. (Force the owning backend to
do it? Temporarily change the access rules so that the data
moves to shared buffers? Dunno, but we sure haven't tried hard.)
However many bugs such a thing might have initially, at least
they'd only put temporary data at hazard.
regards, tom lane
