|
Home > Archive > PostgreSQL Bugs > May 2005 > INSERT deadlocks (bug or feature?)
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
INSERT deadlocks (bug or feature?)
|
|
| evgeny gridasov 2005-05-27, 7:24 am |
| Hi everybody!
Recently, I've discovered an interesting feature (or a bug?) of PostgreSql (checked 7.4.x and 8.0.x):
One may define such tables:
create table ref(
id serial primary key,
name text);
create table dat(
id serial,
ref_id int references ref(id),
comment text);
Let us fill the ref table:
insert into ref(name) values('feature');
insert into ref(name) values('bug');
The test case:
For example we have 2 concurrent transactions (tr1 and tr2):
tr1: begin;
tr2: begin;
tr1: insert into dat(ref_id, comment) values (1, 'all ok');
tr2: insert into dat(ref_id, comment) values (2, 'all ok');
tr1: insert into dat(ref_id, comment) values (2, 'lockup');
tr2: insert into dat(ref_id, comment) values (1, 'deadlock');
.... and we recieve a deadlock!
Easy to understand why: each insert statement generates query like:
SELECT 1 FROM ONLY "public"."ref" x WHERE "id" = $1 FOR UPDATE OF x
So, is this behaviour of postgresql is a bug or feature?
Thanks,
Eugene.
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql
.org
| |
| Tom Lane 2005-05-27, 9:24 am |
| evgeny gridasov <eugrid@fpm.kubsu.ru> writes:
> ... and we recieve a deadlock!
> Easy to understand why: each insert statement generates query like:
> SELECT 1 FROM ONLY "public"."ref" x WHERE "id" = $1 FOR UPDATE OF x
> So, is this behaviour of postgresql is a bug or feature?
An extremely well-known bug ... which is fixed in CVS tip.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql
.org
|
|
|
|
|