[prev in list] [next in list] [prev in thread] [next in thread] 

List:       pgsql-bugs
Subject:    Re: VACUUM can set pages all-frozen without also setting them all-visible
From:       Peter Geoghegan <pg () bowt ! ie>
Date:       2022-03-16 8:22:52
Message-ID: CAH2-Wz=vxaVW0ho95h-dRuix4=3COsfTfQSQA-+FPGkkPcGCSQ () mail ! gmail ! com
[Download RAW message or body]

On Wed, Mar 16, 2022 at 12:24 AM Peter Geoghegan <pg@bowt.ie> wrote:
> It's not clear whether or not it's strictly correct to only set
> VISIBILITYMAP_ALL_FROZEN, but it seems questionable. It's also likely
> to have negative performance implications. Non-aggressive VACUUMs
> won't actually use VISIBILITYMAP_ALL_FROZEN to skip -- they could in
> principle, but they don't.

I believe that at least some of the assertion failures are related to
heap_lock_tuple()'s tendency to clear VISIBILITYMAP_ALL_FROZEN without
also clearing VISIBILITYMAP_ALL_VISIBLE (in its cleared_all_frozen
path).

It's possible for an aggressive VACUUM to see an all-frozen page as
all_visible_according_to_vm that's considered skippable (it's
skippable in principle), that isn't actually skipped due to VACUUM not
crossing SKIP_PAGES_THRESHOLD. The variable
all_visible_according_to_vm from lazy_scan_heap() is inherently
race-prone, which vacuumlazy.c accounts for -- mostly. But I don't
think it's quite safe to assume that the page hasn't changed
(invalidating all_visible_according_to_vm in the process) when an
all_visible_according_to_vm page is still at least all-visible
according to lazy_scan_prune() -- a concurrent heap_lock_tuple() could
make that not work out.

Is it really worth the trouble it takes to make the
visibilitymap_set() interface support "|= VISIBILITYMAP_ALL_FROZEN",
rather than requiring the caller to clobber both of the page's bits?
It seems like it'd be a good idea to just not support that -- that
would make it easy to enforce a rule that says that
VISIBILITYMAP_ALL_FROZEN can never be set on its own.

-- 
Peter Geoghegan


[prev in list] [next in list] [prev in thread] [next in thread]