Simon Riggs wrote:
While watching WAL records float by I noticed some AccessExclusiveLocks occurring unnecessarily during VACUUMs.This is caused by lines 186-189 in lazy_vacuum_rel(), vacuumlazy.c possibly_freeable = vacrelstats->rel_pages - vacrelstats->nonempty_pages; if (possibly_freeable >= REL_TRUNCATE_MINIMUM || possibly_freeable >= vacrelstats->rel_pages / REL_TRUNCATE_FRACTION) lazy_truncate_heap(onerel, vacrelstats); If you look closely you'll see that if rel_pages is small then we willattempt to truncate the heap even if possibly_freeable == 0.
Good catch! And it goes all the way back to 7.4.
While looking at this some more, I notice there is another bug. When VACUUM has nothing at all to do, then it appears that vacrelstats->nonempty_pages is zero, so that possibly_freeable is always set to vacrelstats->rel_pages. vacrelstats->nonempty_pages doesn't appear to be used anywhere else, so nobody notices it is wrongly set.
Hmm, this is a new issue with the visibility map. For pages at the end that are skipped, we don't know if they're empty or not. Currently we assume that they are, but perhaps it would be better to assume they're not? On the other hand, that makes it much less likely that we even try to truncate a relation, and when we do, we wouldn't truncate it as far as we could.
Does anybody think any of the above is intentional? Can I fix?
No. Yes please. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
