database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-12-18 05:01:01 +03:00
Code Activity

Correct comments of "Fix data loss at inplace update after heap_update()".

Browse Source 
This corrects commit a07e03fd8f.

Reported-by: Paul A Jungwirth <pj@illuminatedcomputing.com>
Reported-by: Surya Poondla <s_poondla@apple.com>
Reviewed-by: Paul A Jungwirth <pj@illuminatedcomputing.com>
Discussion: https://postgr.es/m/CA+renyWCW+_2QvXERBQ+mna6ANwAVXXmHKCA-WzL04bZRsjoBA@mail.gmail.com
This commit is contained in:
Noah Misch
2025-12-15 12:19:49 -08:00
parent 7db6809ced
commit 0839fbe400
2 changed files with 12 additions and 8 deletions
Download Patch File Download Diff File Expand all files Collapse all files

11
src/backend/access/heap/heapam.c
View File

@@ -6349,10 +6349,13 @@ heap_abort_speculative(Relation relation, const ItemPointerData *tid)
* Since this is intended for system catalogs and SERIALIZABLE doesn't cover
* DDL, this doesn't guarantee any particular predicate locking.
*
* One could modify this to return true for tuples with delete in progress,
* All inplace updaters take a lock that conflicts with DROP. If explicit
* "DELETE FROM pg_class" is in progress, we'll wait for it like we would an
* update.
* heap_delete() is a rarer source of blocking transactions (xwait). We'll
* wait for such a transaction just like for the normal heap_update() case.
* Normal concurrent DROP commands won't cause that, because all inplace
* updaters take some lock that conflicts with DROP. An explicit SQL "DELETE
* FROM pg_class" can cause it. By waiting, if the concurrent transaction
* executed both "DELETE FROM pg_class" and "INSERT INTO pg_class", our caller
* can find the successor tuple.
*
* Readers of inplace-updated fields expect changes to those fields are
* durable. For example, vac_truncate_clog() reads datfrozenxid from

9
src/backend/access/index/genam.c
View File

@@ -781,10 +781,11 @@ systable_endscan_ordered(SysScanDesc sysscan)
* systable_inplace_update_begin --- update a row "in place" (overwrite it)
*
* Overwriting violates both MVCC and transactional safety, so the uses of
* this function in Postgres are extremely limited. Nonetheless we find some
* places to use it. See README.tuplock section "Locking to write
* inplace-updated tables" and later sections for expectations of readers and
* writers of a table that gets inplace updates. Standard flow:
* this function in Postgres are extremely limited. This makes no effort to
* support updating cache key columns or other indexed columns. Nonetheless
* we find some places to use it. See README.tuplock section "Locking to
* write inplace-updated tables" and later sections for expectations of
* readers and writers of a table that gets inplace updates. Standard flow:
*
* ... [any slow preparation not requiring oldtup] ...
* systable_inplace_update_begin([...], &tup, &inplace_state);