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 | 53F77BCA.9040307@aklaver.com обсуждение исходный текст |
Ответ на | Re: 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?
|
Список | pgsql-general |
On 08/22/2014 10:15 AM, hubert depesz lubaczewski wrote: > On Fri, Aug 22, 2014 at 6:45 PM, Adrian Klaver > <adrian.klaver@aklaver.com <mailto:adrian.klaver@aklaver.com>> wrote: > > 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. > > > Locking is obvious. But why deadlock? There is just single row, and it > shouldn't be able to deadlock on it?! Well both queries are doing SELECT .. FOR UPDATE as well as UPDATE. From what I see there are four queries contending for the same row. > > So what exactly is 'importer' and what does it do? > > > Some software written by some guy. Runs lots of queries, but the only > problem we have is with these transactions. > > Also what is this (59303)? > > > log_line_prefix is '%m %r %p %u %d ' so it's port number. So why are different processes running the exact same queries coming in on different ports? > > depesz -- Adrian Klaver adrian.klaver@aklaver.com
В списке pgsql-general по дате отправления: