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. Another thought is to have a different LockTagType that signals a transaction that's doing the INSERT/ON DUPLICATE thingy, and remote backends sleep on that instead of the regular transaction lock. That different lock type could be released and reacquired as proposed by Heikki above without danger of unintended consequences. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
