Heikki Linnakangas wrote:
> On 04.06.2011 19:19, Tom Lane wrote:
>> Heikki Linnakangas writes:
>>> On 03.06.2011 21:04, Kevin Grittner wrote:
>>>> Also, if anyone has comments or hints about the placement of
>>>> those calls, I'd be happy to receive them.
>>
>>> heap_drop_with_catalog() schedules the relation for deletion at
>>> the end of transaction, but it's still possible that the
>>> transaction aborts and the heap doesn't get dropped after all. If
>>> you put the DropAllPredicateLocksFromTable() call there, and the
>>> transaction later aborts, you've lost all the locks already.
>>
>> But on the third thought: is that wrong? Surely locks taken by an
>> aborted transaction can be discarded.
>
> These are predicate locks - there can be "locks" on the table
> belonging to transactions that have already committed.
It took me a while to think this through, but if the transaction (T1)
which reads the table to create the SIREAD lock overlaps another
transaction (T2) with which it might interact to create a dangerous
structure, and T2 has not yet accessed the table in any way,
then after T1 commits a third transaction (T3) could try to drop the
table but roll back, and T2 could still proceed to do a write which
conflicts with the predicate lock.
That certainly sounds like a low frequency combination of events, but
one which can't be ignored if we want correct behavior (i.e., no
false negatives).
-Kevin
