diff options
author | Noah Misch <noah@leadboat.com> | 2024-09-24 15:25:18 -0700 |
---|---|---|
committer | Noah Misch <noah@leadboat.com> | 2024-09-24 15:25:23 -0700 |
commit | f51b34b3eddbc501063f7b8ac470d26ce4e18a48 (patch) | |
tree | 415aedebc9c0712f306bf5801c92dac821571fc8 /src/backend/executor/nodeHashjoin.c | |
parent | 82c2d9e0220666ff698c226db41cb119ed4bfa44 (diff) | |
download | postgresql-f51b34b3eddbc501063f7b8ac470d26ce4e18a48.tar.gz postgresql-f51b34b3eddbc501063f7b8ac470d26ce4e18a48.zip |
For inplace update durability, make heap_update() callers wait.
The previous commit fixed some ways of losing an inplace update. It
remained possible to lose one when a backend working toward a
heap_update() copied a tuple into memory just before inplace update of
that tuple. In catalogs eligible for inplace update, use LOCKTAG_TUPLE
to govern admission to the steps of copying an old tuple, modifying it,
and issuing heap_update(). This includes MERGE commands. To avoid
changing most of the pg_class DDL, don't require LOCKTAG_TUPLE when
holding a relation lock sufficient to exclude inplace updaters.
Back-patch to v12 (all supported versions). In v13 and v12, "UPDATE
pg_class" or "UPDATE pg_database" can still lose an inplace update. The
v14+ UPDATE fix needs commit 86dc90056dfdbd9d1b891718d2e5614e3e432f35,
and it wasn't worth reimplementing that fix without such infrastructure.
Reviewed by Nitin Motiani and (in earlier versions) Heikki Linnakangas.
Discussion: https://postgr.es/m/20231027214946.79.nmisch@google.com
Diffstat (limited to 'src/backend/executor/nodeHashjoin.c')
0 files changed, 0 insertions, 0 deletions