Re: lazy_truncate_heap()

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 will
> attempt 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