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
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
