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.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
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
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/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.
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.