- Notifications
You must be signed in to change notification settings - Fork5
Commit27846f0
committed
Optimize locking a tuple already locked by another subxact
Locking and updating the same tuple repeatedly led to some strangemultixacts being created which had several subtransactions of the sameparent transaction holding locks of the same strength. However,once a subxact of the current transaction holds a lock of a givenstrength, it's not necessary to acquire the same lock again. This madesome coding patterns much slower than required.The fix is twofold. First we change HeapTupleSatisfiesUpdate to returnHeapTupleBeingUpdated for the case where the current transaction isalready a single-xid locker for the given tuple; it used to returnHeapTupleMayBeUpdated for that case. The new logic is simpler, and thechange to pgrowlocks is a testament to that: previously we needed tocheck for the single-xid locker separately in a very ugly way. Thattest is simpler now.As fallout from the HTSU change, some of its callers need to be amendedso that tuple-locked-by-own-transaction is taken into account in theBeingUpdated case rather than the MayBeUpdated case. For many of themthere is no difference; but heap_delete() and heap_update now checkexplicitely and do not grab tuple lock in that case.The HTSU change also means that routine MultiXactHasRunningRemoteMembersintroduced in commit11ac4c7 is no longer necessary and can beremoved; the case that used to require it is now handled naturally asresult of the changes to heap_delete and heap_update.The second part of the fix to the performance issue is to adjustheap_lock_tuple to avoid the slowness:1. Previously we checked for the case that our own transaction alreadyheld a strong enough lock and returned MayBeUpdated, but only in themultixact case. Now we do it for the plain Xid case as well, whichsaves having to LockTuple.2. If the current transaction is the only locker of the tuple (but witha lock not as strong as what we need; otherwise it would have beencaught in the check mentioned above), we can skip sleeping on themultixact, and instead go straight to create an updated multixact withthe additional lock strength.3. Most importantly, make sure that both the single-xid-locker case andthe multixact-locker case optimization are applied always. We do thisby checking both in a single place, rather than them appearing in twoseparate portions of the routine -- something that is made possible bythe HeapTupleSatisfiesUpdate API change. Previously we would only checkfor the single-xid case when HTSU returned MayBeUpdated, and onlychecked for the multixact case when HTSU returned BeingUpdated. Thiswas at odds with what HTSU actually returned in one case: if our owntransaction was locker in a multixact, it returned MayBeUpdated, so theoptimization never applied. This is what led to the large multixacts inthe first place.Per bug report #8470 by Oskari Saarenmaa.1 parent8a0d34e commit27846f0
File tree
5 files changed
+237
-269
lines changed- contrib/pgrowlocks
- src
- backend
- access
- heap
- transam
- utils/time
- include/access
5 files changed
+237
-269
lines changedLines changed: 2 additions & 7 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
136 | 136 | | |
137 | 137 | | |
138 | 138 | | |
139 | | - | |
140 | | - | |
| 139 | + | |
141 | 140 | | |
142 | | - | |
143 | | - | |
144 | | - | |
145 | | - | |
146 | | - | |
| 141 | + | |
147 | 142 | | |
148 | 143 | | |
149 | 144 | | |
| |||
0 commit comments
Comments
(0)