Re: (auto)vacuum truncate exclusive lock

Jeff Janes <jeff(dot)janes(at)gmail(dot)com> writes:
> I guess I'm a couple releases late to review the "autovacuum truncate
> exclusive lock" patch (a79ae0bc0d454b9f2c95a), but this patch did not only
> affect autovac, it affects manual vacuum as well (as did the original
> behavior it is a modification of). So the compiler constants are misnamed,
> and the elog message when it triggers is misleading. (Is it also
> misleading to just say "vacuum"? Does it need to say "(auto)vacuum"?)

I just came to look at this via a complaint in pgsql-admin. I'm not
convinced that we should consider the new behavior to be sane.
Automatic exclusive-lock abandonment makes sense for autovacuum, but
when the user has told us to vacuum, ISTM we should do it. I can see
there might be differing opinions on that though.

> Also, I think that permanently boycotting doing autoanalyze because someone
> is camping out on an access share lock (or because there are a never-ending
> stream of overlapping locks) and so the truncation cannot be done is a bit
> drastic, especially for inclusion in a point release.

It's worse than that, it breaks manual VACUUM ANALYZE too (as per -admin
complaint). I think this aspect is completely wrong, whether or not
you consider that dropping the exclusive lock early is sane for manual
vacuum. If we were told to do an analyze, we should press on and do it.

Thoughts?

regards, tom lane