Re: Fixing a couple of buglets in how VACUUM sets visibility map bits
Peter Geoghegan <pg@bowt.ie>
From: Peter Geoghegan <pg@bowt.ie>
To: Andres Freund <andres@anarazel.de>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
Robert Haas <robertmhaas@gmail.com>
Date: 2023-01-09T20:04:15Z
Lists: pgsql-hackers
On Mon, Jan 9, 2023 at 11:44 AM Andres Freund <andres@anarazel.de> wrote: > I think that's just an imprecise formulation though - the problem is that we > can call visibilitymap_set() with just VISIBILITYMAP_ALL_FROZEN, even though > VISIBILITYMAP_ALL_VISIBLE was concurrently unset. That's correct. You're right that my description of the problem from the commit message was confusing. But we're on the same page about the problem now. > ISTM that we ought to update all_visible_according_to_vm from > PageIsAllVisible() once we've locked the page. Even if we avoid this specific > case, it seems a recipe for future bugs to have a potentially outdated > variable around. I basically agree, but some of the details are tricky. As I mentioned already, my work on visibility map snapshots just gets rid of all_visible_according_to_vm, which is my preferred long term approach. We will very likely need to keep all_visible_according_to_vm as a cache for performance reasons for as long as we have SKIP_PAGES_THRESHOLD. Can we just update all_visible_according_to_vm using PageIsAllVisible(), without making all_visible_according_to_vm significantly less useful as a cache? Maybe. Not sure offhand. -- Peter Geoghegan
Commits
-
Tighten up VACUUM's approach to setting VM bits.
- 980ae173108e 16.0 landed
-
Make lazy_vacuum_heap_rel match lazy_scan_heap.
- d30b499997ca 16.0 landed
-
vacuumlazy.c: Tweak local variable name.
- 8c233cf86b6d 16.0 landed
-
vacuumlazy.c: Save get_database_name() in vacrel.
- 54afdcd6182a 16.0 landed
-
Avoid special XID snapshotConflictHorizon values.
- 6daeeb1f9196 16.0 landed
-
Change the format of the VM fork to add a second bit per page.
- a892234f830e 9.6.0 cited