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

Revert "For inplace update, send nontransactional invalidations."

Browse Source 
This reverts commit 95c5acb3fc (v17) and
counterparts in each other non-master branch.  If released, that commit
would have caused a worst-in-years minor release regression, via
undetected LWLock self-deadlock.  This commit and its self-deadlock fix
warrant more bake time in the master branch.

Reported by Alexander Lakhin.

Discussion: https://postgr.es/m/10ec0bc3-5933-1189-6bb8-5dec4114558e@gmail.com
This commit is contained in:
Noah Misch
2024-11-02 09:05:00 -07:00
parent e50f9de98d
commit 27642d8908
12 changed files with 132 additions and 320 deletions
Download Patch File Download Diff File Expand all files Collapse all files

26
src/backend/replication/logical/decode.c
View File

@@ -483,19 +483,23 @@ heap_decode(LogicalDecodingContext *ctx, XLogRecordBuffer *buf)
/*
* Inplace updates are only ever performed on catalog tuples and
* can, per definition, not change tuple visibility. Inplace
* updates don't affect storage or interpretation of table rows,
* so they don't affect logicalrep_write_tuple() outcomes. Hence,
* we don't process invalidations from the original operation. If
* inplace updates did affect those things, invalidations wouldn't
* make it work, since there are no snapshot-specific versions of
* inplace-updated values. Since we also don't decode catalog
* tuples, we're not interested in the record's contents.
* can, per definition, not change tuple visibility. Since we
* don't decode catalog tuples, we're not interested in the
* record's contents.
*
* WAL contains likely-unnecessary commit-time invals from the
* CacheInvalidateHeapTuple() call in heap_inplace_update().
* Excess invalidation is safe.
* In-place updates can be used either by XID-bearing transactions
* (e.g. in CREATE INDEX CONCURRENTLY) or by XID-less
* transactions (e.g. VACUUM). In the former case, the commit
* record will include cache invalidations, so we mark the
* transaction as catalog modifying here. Currently that's
* redundant because the commit will do that as well, but once we
* support decoding in-progress relations, this will be important.
*/
if (!TransactionIdIsValid(xid))
break;
(void) SnapBuildProcessChange(builder, xid, buf->origptr);
ReorderBufferXidSetCatalogChanges(ctx->reorder, xid, buf->origptr);
break;
case XLOG_HEAP_CONFIRM: