From: | Peter Geoghegan <pg(at)heroku(dot)com> |
---|---|
To: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)2ndquadrant(dot)com> |
Subject: | Re: Promise index tuples for UPSERT |
Date: | 2014-10-02 23:05:10 |
Message-ID: | CAM3SWZRxdnjVMpjQW7Amomo-85Ewi_s-gsKMaBZLdOnZ+LwTBQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Oct 1, 2014 at 12:59 PM, Peter Geoghegan <pg(at)heroku(dot)com> wrote:
> On Wed, Oct 1, 2014 at 12:54 PM, Heikki Linnakangas
> <hlinnakangas(at)vmware(dot)com> wrote:
>> XactLockTableWait() waits until the end of transaction, that's not you want
>> here. If the backend that inserted the promise tuple decides to not proceed
>> with the insertion, and removes the promise tuple, the backend waiting on it
>> needs to be woken up more or less immediately, not when the transaction
>> completes.
>
> Simon has not been inconsistent here: he has said that deadlocks may
> be possible. I happen to think that allowing them would be a major
> mistake on our part, but that's another story.
Don't forget that not waiting on XactLockTableWait(), but rather
waiting on a "speculative insertion token" wasn't just the thing that
made your prototype not deadlock - it was also the thing that made its
performance more or less comparable to that of my original value
locking design. Your prototype performed only a fraction as well as my
design before that last revision.
So that's two *excellent* reasons to not use XactLockTableWait() here.
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2014-10-02 23:10:46 | Re: NEXT VALUE FOR <sequence> |
Previous Message | Thomas Munro | 2014-10-02 23:01:06 | Re: NEXT VALUE FOR <sequence> |