database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-08-25 20:23:07 +03:00
Code Activity

For inplace update durability, make heap_update() callers wait.

Browse Source 
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 86dc90056d,
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
This commit is contained in:
Noah Misch
2024-09-24 15:25:18 -07:00
parent a8ad1929d2
commit 14c57cb639
17 changed files with 423 additions and 34 deletions
Download Patch File Download Diff File Expand all files Collapse all files

42
src/backend/access/heap/README.tuplock
View File

@@ -154,6 +154,48 @@ The following infomask bits are applicable:
We currently never set the HEAP_XMAX_COMMITTED when the HEAP_XMAX_IS_MULTI bit
is set.
Locking to write inplace-updated tables
---------------------------------------
If IsInplaceUpdateRelation() returns true for a table, the table is a system
catalog that receives systable_inplace_update_begin() calls. Preparing a
heap_update() of these tables follows additional locking rules, to ensure we
don't lose the effects of an inplace update. In particular, consider a moment
when a backend has fetched the old tuple to modify, not yet having called
heap_update(). Another backend's inplace update starting then can't conclude
until the heap_update() places its new tuple in a buffer. We enforce that
using locktags as follows. While DDL code is the main audience, the executor
follows these rules to make e.g. "MERGE INTO pg_class" safer. Locking rules
are per-catalog:
pg_class systable_inplace_update_begin() callers: before the call, acquire a
lock on the relation in mode ShareUpdateExclusiveLock or stricter. If the
update targets a row of RELKIND_INDEX (but not RELKIND_PARTITIONED_INDEX),
that lock must be on the table. Locking the index rel is not necessary.
(This allows VACUUM to overwrite per-index pg_class while holding a lock on
the table alone.) systable_inplace_update_begin() acquires and releases
LOCKTAG_TUPLE in InplaceUpdateTupleLock, an alias for ExclusiveLock, on each
tuple it overwrites.
pg_class heap_update() callers: before copying the tuple to modify, take a
lock on the tuple, a ShareUpdateExclusiveLock on the relation, or a
ShareRowExclusiveLock or stricter on the relation.
SearchSysCacheLocked1() is one convenient way to acquire the tuple lock.
Most heap_update() callers already hold a suitable lock on the relation for
other reasons and can skip the tuple lock. If you do acquire the tuple
lock, release it immediately after the update.
pg_database: before copying the tuple to modify, all updaters of pg_database
rows acquire LOCKTAG_TUPLE. (Few updaters acquire LOCKTAG_OBJECT on the
database OID, so it wasn't worth extending that as a second option.)
Ideally, DDL might want to perform permissions checks before LockTuple(), as
we do with RangeVarGetRelidExtended() callbacks. We typically don't bother.
LOCKTAG_TUPLE acquirers release it after each row, so the potential
inconvenience is lower.
Reading inplace-updated columns
-------------------------------