On 12/20/2013 10:56 PM, Alvaro Herrera wrote:
Robert Haas escribió:
On Fri, Dec 20, 2013 at 3: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.
That particular mechanism sounds like a recipe for unintended consequences.
Yep, what I thought too.
There are probably other ways to make that general idea work though. I
didn't follow this thread carefully, but is the idea that there would be
many promise tuples "live" at any one time, or only one? Because if
there's only one, or a very limited number, it might be workable to
sleep on that tuple's lock instead of the xact's lock.
Only one.
heap_update() and heap_delete() also grab a heavy-weight lock on the
tuple, before calling XactLockTableWait(). _bt_doinsert() does not, but
it could. Perhaps we can take advantage of that.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
