Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE

On Fri, Dec 20, 2013 at 12:39 PM, Heikki Linnakangas
<hlinnakangas(at)vmware(dot)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