WAL-log inplace update before revealing it to other sessions.
A buffer lock won't stop a reader having already checked tuple
visibility. If a vac_update_datfrozenid() and then a crash happened
during inplace update of a relfrozenxid value, datfrozenxid could
overtake relfrozenxid. That could lead to "could not access status of
transaction" errors.
Back-patch to v14 - v17. This is a back-patch of commits:
- 8e7e672cdaa6bfec85d4d5dd9be84159df23bb41
(main change, on master, before v18 branched)
- 818013665259d4242ba641aad705ebe5a3e2db8e
(defect fix, on master, before v18 branched)
It reverses commit bc6bad88572501aecaa2ac5d4bc900ac0fd457d5, my revert
of the original back-patch.
In v14, this also back-patches the assertion removal from commit
7fcf2faf9c7dd473208fd6d5565f88d7f733782b.
Discussion: https://postgr.es/m/20240620012908.92.nmisch@google.com
Backpatch-through: 14-17
Branch
------
REL_17_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/d3e5d89504484d69bc41e66fc2c2346ec0da6b07
Modified Files
--------------
src/backend/access/heap/README.tuplock | 4 +-
src/backend/access/heap/heapam.c | 68 +++++++++++++++++++++++++++-------
src/include/storage/proc.h | 8 ++--
3 files changed, 59 insertions(+), 21 deletions(-)
