If a tuple was locked by transaction A, and transaction B updated it,
the new version of the tuple created by B would be locked by A, yet
visible only to B; due to an oversight in HeapTupleSatisfiesUpdate, the
lock held by A wouldn't get checked if transaction B later deleted (or
key-updated) the new version of the tuple. This might cause referential
integrity checks to give false positives (that is, allow deletes that
should have been rejected).
This is an easy oversight to have made, because prior to improved tuple
locks in commit
|
||
---|---|---|
.. | ||
common | ||
gin | ||
gist | ||
hash | ||
heap | ||
index | ||
nbtree | ||
rmgrdesc | ||
spgist | ||
transam | ||
Makefile |