Clear all-frozen visibilitymap status when locking tuples.
Since a892234 & fd31cd265 the visibilitymap's freeze bit is used to
avoid vacuuming the whole relation in anti-wraparound vacuums. Doing so
correctly relies on not adding xids to the heap without also unsetting
the visibilitymap flag. Tuple locking related code has not done so.
To allow selectively resetting all-frozen - to avoid pessimizing
heap_lock_tuple - allow to selectively reset the all-frozen with
visibilitymap_clear(). To avoid having to use
visibilitymap_get_status (e.g. via VM_ALL_FROZEN) inside a critical
section, have visibilitymap_clear() return whether any bits have been
reset.
There's a remaining issue (denoted by XXX): After the PageIsAllVisible()
check in heap_lock_tuple() and heap_lock_updated_tuple_rec() the page
status could theoretically change. Practically that currently seems
impossible, because updaters will hold a page level pin already. Due to
the next beta coming up, it seems better to get the required WAL magic
bump done before resolving this issue.
The added flags field fields to xl_heap_lock and xl_heap_lock_updated
require bumping the WAL magic. Since there's already been a catversion
bump since the last beta, that's not an issue.
Reviewed-By: Robert Haas, Amit Kapila and Andres Freund
Author: Masahiko Sawada, heavily revised by Andres Freund
Discussion: CAEepm=3fWAbWryVW9swHyLTY4sXVf0xbLvXqOwUoDiNCx9mBjQ@mail.gmail.com
Backpatch: -
Branch
------
master
Details
-------
http://git.postgresql.org/pg/commitdiff/eca0f1db14ac92d91d54eca8eeff2d15ccd797fa
Modified Files
--------------
src/backend/access/heap/heapam.c | 207 +++++++++++++++++++++++++-------
src/backend/access/heap/visibilitymap.c | 18 ++-
src/backend/access/rmgrdesc/heapdesc.c | 6 +-
src/backend/commands/vacuumlazy.c | 6 +-
src/include/access/heapam_xlog.h | 9 +-
src/include/access/visibilitymap.h | 4 +-
src/include/access/xlog_internal.h | 2 +-
7 files changed, 194 insertions(+), 58 deletions(-)