Daniel Wood wrote: > In 9.3 I can delete the parent of a parent-child relation if the child row > is an uncommitted insert and I first update the parent.
Interesting test case, thanks. I traced through it and promptly noticed that the problem is that HeapTupleSatisfiesUpdate is failing to consider the case that there are foreign lockers when a tuple was created by our own transaction. In the past, a tuple created by our own transaction can't possibly be seen by other transactions -- so it wouldn't be possible for them to lock them. But this is no longer the case, because an UPDATE can carry forward the locks from the previous version of the tuple. The fix for the immediate bug is to add some code to HTSU so that it checks for locks by other transactions even when the tuple was created by us. I haven't looked at the other tqual routines yet, but I imagine they will need equivalent fixes. One thought on the whole HTSU issue is that it's a bit strange that it is returning HeapTupleBeingUpdated when the tuple is actually only locked; and thus the callers can update the tuple in that case anyway. While I haven't explored the idea fully, perhaps we should consider adding a new return code to HTSU, with the meaning "this tuple is not updated, but it is locked by someone". Then it's the caller's responsibility to check the lock for conflicts, and perhaps add more locks. When BeingUpdate is returned, then a tuple cannot possibly be updated. This may help disentangling the mess in the heapam.c routines a bit ... or it may not (at least heap_lock_tuple will still need to consider doing some stuff in the BeingUpdated case, so it's unlikely that we will see much simplification there). Another consideration is that perhaps it's too late for the 9.3 series for a change this large. I will start working on a patch for this tomorrow. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
