Re: BUG #13598: Hang forever, but must rollback (deadlock)

On Mon, Aug 31, 2015 at 9:39 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:

> On 2015-08-31 08:03:51 +0000, immortaldragonm(at)gmail(dot)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.
>

​By 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=104.
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.