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.
