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.
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.
Both of these bugs are minor, but the effect of either/both of them is
to cause more AccessExclusiveLocks than we might expect.
For Hot Standby this means that many VACUUMs take AccessExclusiveLocks
on relations, which would potentially lead to having queries cancelled
for no reason at all.
Does anybody think any of the above is intentional? Can I fix?
-- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support