On Fri, Dec 20, 2013 at 12:39 PM, Heikki Linnakangas <hlinnakan...@vmware.com> wrote: > Hmm. If I understand the problem correctly, it's that as soon as another > backend sees the tuple you've inserted and calls XactLockTableWait(), it > will not stop waiting even if we later decide to kill the already-inserted > tuple. > > One approach to fix that would be to release and immediately re-acquire the > transaction-lock, when you kill an already-inserted tuple. Then teach the > callers of XactLockTableWait() to re-check if the tuple is still alive. I'm > just waving hands here, but the general idea is to somehow wake up others > when you kill the tuple.
While mulling this over further, I had an idea about this: suppose we marked the tuple in some fashion that indicates that it's a promise tuple. I imagine an infomask bit, although the concept makes me wince a bit since we don't exactly have bit space coming out of our ears there. Leaving that aside for the moment, whenever somebody looks at the tuple with a mind to calling XactLockTableWait(), they can see that it's a promise tuple and decide to wait on some other heavyweight lock instead. The simplest thing might be for us to acquire a heavyweight lock on the promise tuple before making index entries for it, and then have callers wait on that instead always instead of transitioning from the tuple lock to the xact lock. Then we don't need to do anything screwy like releasing our transaction lock; if we decide to kill the promise tuple, we have a lock to release that pertains specifically to that tuple. This might be a dumb idea; I'm just thinking out loud. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers