- Notifications
You must be signed in to change notification settings - Fork5
Commiteca0f1d
committed
Clear all-frozen visibilitymap status when locking tuples.
Sincea892234 &fd31cd2 the visibilitymap's freeze bit is used toavoid vacuuming the whole relation in anti-wraparound vacuums. Doing socorrectly relies on not adding xids to the heap without also unsettingthe visibilitymap flag. Tuple locking related code has not done so.To allow selectively resetting all-frozen - to avoid pessimizingheap_lock_tuple - allow to selectively reset the all-frozen withvisibilitymap_clear(). To avoid having to usevisibilitymap_get_status (e.g. via VM_ALL_FROZEN) inside a criticalsection, have visibilitymap_clear() return whether any bits have beenreset.There's a remaining issue (denoted by XXX): After the PageIsAllVisible()check in heap_lock_tuple() and heap_lock_updated_tuple_rec() the pagestatus could theoretically change. Practically that currently seemsimpossible, because updaters will hold a page level pin already. Due tothe next beta coming up, it seems better to get the required WAL magicbump done before resolving this issue.The added flags field fields to xl_heap_lock and xl_heap_lock_updatedrequire bumping the WAL magic. Since there's already been a catversionbump since the last beta, that's not an issue.Reviewed-By: Robert Haas, Amit Kapila and Andres FreundAuthor: Masahiko Sawada, heavily revised by Andres FreundDiscussion: CAEepm=3fWAbWryVW9swHyLTY4sXVf0xbLvXqOwUoDiNCx9mBjQ@mail.gmail.comBackpatch: -1 parent6563208 commiteca0f1d
File tree
7 files changed
+194
-58
lines changed- src
- backend
- access
- heap
- rmgrdesc
- commands
- include/access
7 files changed
+194
-58
lines changed0 commit comments
Comments
(0)