Re: deadlock in single-row select-for-update + update scenario? How could it happen?

Поиск
Список
Период
Сортировка
От hubert depesz lubaczewski
Тема Re: deadlock in single-row select-for-update + update scenario? How could it happen?
Дата
Msg-id CAKrjmheBgqdhUmeNMymG=dJy=zgRT7PZ9Vj1VkNeMkBX0ND6=w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: deadlock in single-row select-for-update + update scenario? How could it happen?  (Adrian Klaver <adrian.klaver@aklaver.com>)
Список pgsql-general
Дерево обсуждения
On Fri, Aug 22, 2014 at 8:33 PM, Adrian Klaver <adrian.klaver@aklaver.com> wrote:
Not sure, just the combination of parallel operations and remote connections seemed to be an avenue to explore. Given that everything is local, turns out it was dead end.
Looking at the pastebin log again, am I reading it right that the first process actually COMMITs properly?
Also is there a trigger in the mix that might be fouling things up?

Please note that the pastebin log is split by backend pid, and only in backend-pid groups sorted by timestamp.

66014 started transaction later, and committed, while 66017, which started transaction earlier, and actually obtained lock earlier - got killed by deadlock resolution.

There are no triggers aside from some (~10) fkeys.

depesz

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

Предыдущее
От: Soni M
Дата:
Сообщение: Re: Query planner question
Следующее
От: hubert depesz lubaczewski
Дата:
Сообщение: Re: deadlock in single-row select-for-update + update scenario? How could it happen?