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

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE
Дата
Msg-id 20131220205632.GH22570@eldon.alvh.no-ip.org
обсуждение исходный текст
Ответ на Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Список pgsql-hackers
Robert Haas escribió:
> On Fri, Dec 20, 2013 at 3:39 PM, Heikki Linnakangas
> <hlinnakangas@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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE
Следующее
От: Andres Freund
Дата:
Сообщение: Re: shared memory message queues