Kevin Grittner <kgri...@ymail.com> writes:
> OK, will review that to confirm;but assuming that's right, and
> nobody else is already working on a fix, I propose to do the
> following:
> (1) Restore the prior behavior of the VACUUM command. This was
> only ever intended to be a fix for a serious autovacuum problem
> which caused many users serious performance problems -- in some
> cases including unscheduled down time. I also saw sites where,
> having been bitten by this, they disabled autovacuum and later ran
> into problems with bloat and/or xid wraparound.
> (2) If autovacuum decides to try to truncate but the lock cannot
> be initially acquired, and analyze is requested, skip the
> truncation and do the autoanalyze. If the table is so hot that we
> cannot get the lock, the space may get re-used soon, and if not
> there is a good chance another autovacuum will trigger soon. If
> the user really wants the space released to the OS immediately,
> they can run a manual vacuum to force the issue.
I think that the minimum appropriate fix here is to revert the hunk
I quoted, ie take out the suppression of stats reporting and analysis.
However, we're still thinking too small. I've been wondering whether we
couldn't entirely remove the dirty, awful kluges that were installed in
the lock manager to kill autovacuum when somebody blocked behind it.
This mechanism should ensure that AV never takes an exclusive lock
for long enough to be a serious problem, so do we need that anymore?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
