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

Поиск
Список
Период
Сортировка
От Adrian Klaver
Тема Re: deadlock in single-row select-for-update + update scenario? How could it happen?
Дата
Msg-id 53F773BA.7030309@aklaver.com
обсуждение исходный текст
Ответ на deadlock in single-row select-for-update + update scenario? How could it happen?  (hubert depesz lubaczewski <depesz@gmail.com>)
Ответы Re: deadlock in single-row select-for-update + update scenario? How could it happen?  (hubert depesz lubaczewski <depesz@gmail.com>)
Список pgsql-general
On 08/22/2014 09:29 AM, hubert depesz lubaczewski wrote:
> I have developer with pg 9.3.5, which is reporing something really strange.
>
> He runs importer, which does, in single transaction:
>
> begin;
> select * from table where pkey = <value> limit 1 for update;
> update table set ... where pkey = <the same_value>;
> commit;
>
> and two backends running the same transaction deadlock.
>
> I checked for duplicated rows with the same pkey value - none are there.
> And frankly - I'm out of ideas.
>
> What could be wrong in such case?

So process 66017 and 66014 are blocking each because they are running
the exact same queries. The interesting part is the process with the
lower pid is starting later then the none with the higher pid.

So what exactly is 'importer' and what does it do?

Also what is this (59303)?

>
> Detailed logs, with just some obfuscation:
> https://depesz.privatepaste.com/0594a93459
>
> depesz


--
Adrian Klaver
adrian.klaver@aklaver.com


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

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