Обсуждение: BUG #13598: Hang forever, but must rollback (deadlock)
The following bug has been logged on the website: Bug reference: 13598 Logged by: ImmortalDragon Email address: immortaldragonm@gmail.com PostgreSQL version: 9.4.4 Operating system: windows Description: table: CREATE TABLE t1(id integer primary key); libpq code: c1 = PQconnectdb(conninfo); c2 = PQconnectdb(conninfo); res1 = PQexec(c1, "BEGIN"); PQclear(res1); res1 = PQexec(c1, "INSERT INTO t1 (id) VALUES (104)"); PQclear(res1); res2 = PQexec(c2, "BEGIN"); PQclear(res2); res2 = PQexec(c2, "INSERT INTO t1 (id) VALUES (104)"); //hang here PQclear(res2); res2 = PQexec(c2, "END"); PQclear(res2); res1 = PQexec(c1, "END"); PQclear(res1); I use different connection in one thread (like different programs, as i undestand). I think, that postgres must detect deadlock and rollback one of transaction with error. But it hang forever. Why? i think it's bug. deadlock_timeout - default (1s) i check other version of postgres, same result.
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. Greetings, Andres Freund
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.