database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-08-31 17:02:12 +03:00
Code Activity

Revert "Avoid spurious deadlocks when upgrading a tuple lock"

Browse Source 
This reverts commits 3da73d6839 and de87a084c0.

This code has some tricky corner cases that I'm not sure are correct and
not properly tested anyway, so I'm reverting the whole thing for next
week's releases (reintroducing the deadlock bug that we set to fix).
I'll try again afterwards.

Discussion: https://postgr.es/m/E1hbXKQ-0003g1-0C@gemulon.postgresql.org
This commit is contained in:
Alvaro Herrera
2019-06-16 22:24:21 -04:00
parent 16c4e76f1b
commit 9d20b0ec8f
5 changed files with 21 additions and 280 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -36,16 +36,6 @@ do LockTuple as well, if there is any conflict, to ensure that they don't
starve out waiting exclusive-lockers. However, if there is not any active
conflict for a tuple, we don't incur any extra overhead.
We make an exception to the above rule for those lockers that already hold
some lock on a tuple and attempt to acquire a stronger one on it. In that
case, we skip the LockTuple() call even when there are conflicts, provided
that the target tuple is being locked, updated or deleted by multiple sessions
concurrently. Failing to skip the lock would risk a deadlock, e.g., between a
session that was first to record its weaker lock in the tuple header and would
be waiting on the LockTuple() call to upgrade to the stronger lock level, and
another session that has already done LockTuple() and is waiting for the first
session transaction to release its tuple header-level lock.
We provide four levels of tuple locking strength: SELECT FOR UPDATE obtains an
exclusive lock which prevents any kind of modification of the tuple. This is
the lock level that is implicitly taken by DELETE operations, and also by