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
