Re: BUG #13598: Hang forever, but must rollback (deadlock)
От | David G. Johnston |
---|---|
Тема | Re: BUG #13598: Hang forever, but must rollback (deadlock) |
Дата | |
Msg-id | CAKFQuwYxgq6tDKLCXJXE9-B4=P+zF+Q747MqTiatj_1BtvU0zA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #13598: Hang forever, but must rollback (deadlock) (Andres Freund <andres@anarazel.de>) |
Список | pgsql-bugs |
On Mon, Aug 31, 2015 at 9:39 AM, Andres Freund <andres@anarazel.de> wrote: > On 2015-08-31 08:03:51 +0000, immortaldragonm@gmail.com wrote: > > I think, that postgres must detect deadlock and rollback one of > transaction > > with error. But it hang forever. Why? i think it's bug. > > It's not a deadlock postgres can handle - the blocking part is in your > application. If these were submitted by two independent clients it'd > work. > =E2=80=8BBy this: "In concurrent programming, a deadlock is a situation in which two or more competing actions are each waiting for the other to finish, and thus neither ever does." https://en.wikipedia.org/wiki/Deadlock definition it is not a deadlock in the first place. "c1" is not waiting for "c2" to finish and can happily go about its business with id=3D104. However, your application never gives c1 the next command because it is stubbornly waiting for "c2" to perform its insert - which it cannot due to the lock held by "c1". Lock testing can be done within a single thread but deadlock testing implies that both connections need to simultaneously be attempting to execute a command - which a single program cannot accomplish without threading. David J.
В списке pgsql-bugs по дате отправления: