aboutsummaryrefslogtreecommitdiff
path: root/contrib/postgres_fdw/postgres_fdw.c
diff options
context:
space:
mode:
authorAndres Freund <andres@anarazel.de>2021-04-06 09:24:50 -0700
committerAndres Freund <andres@anarazel.de>2021-04-06 09:24:50 -0700
commit90c885cdab8bc5a5f12a243774fa0db51002a2fd (patch)
treea4b97b0c878d7a4bc64bc80630f7b7b1f9cf994d /contrib/postgres_fdw/postgres_fdw.c
parent8523492d4e349c4714aa2ab0291be175a88cb4fc (diff)
downloadpostgresql-90c885cdab8bc5a5f12a243774fa0db51002a2fd.tar.gz
postgresql-90c885cdab8bc5a5f12a243774fa0db51002a2fd.zip
Increment xactCompletionCount during subtransaction abort.
Snapshot caching, introduced in 623a9ba79b, did not increment xactCompletionCount during subtransaction abort. That could lead to an older snapshot being reused. That is, at least as far as I can see, not a correctness issue (for MVCC snapshots there's no difference between "in progress" and "aborted"). The only difference between the old and new snapshots would be a newer ->xmax. While HeapTupleSatisfiesMVCC makes the same visibility determination, reusing the old snapshot leads HeapTupleSatisfiesMVCC to not set HEAP_XMIN_INVALID. Which subsequently causes the kill_prior_tuple optimization to not kick in (via HeapTupleIsSurelyDead() returning false). The performance effects of doing the same index-lookups over and over again is how the issue was discovered... Fix the issue by incrementing xactCompletionCount in XidCacheRemoveRunningXids. It already acquires ProcArrayLock exclusively, making that an easy proposition. Add a test to ensure that kill_prior_tuple prevents index growth when it involves aborted subtransaction of the current transaction. Author: Andres Freund Discussion: https://postgr.es/m/20210406043521.lopeo7bbigad3n6t@alap3.anarazel.de Discussion: https://postgr.es/m/20210317055718.v6qs3ltzrformqoa%40alap3.anarazel.de
Diffstat (limited to 'contrib/postgres_fdw/postgres_fdw.c')
0 files changed, 0 insertions, 0 deletions