Re: deadlock

From: Scott Marlowe <smarlowe(at)g2switchworks(dot)com>
To: Alexey Nalbat <nalbat(at)price(dot)ru>
Cc: pgsql general <pgsql-general(at)postgresql(dot)org>, developers(at)price(dot)ru
Subject: Re: deadlock
Date: 2007-04-12 20:33:59
Message-ID: 1176410039.13754.21.camel@state.g2switchworks.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Mon, 2007-04-09 at 04:24, Alexey Nalbat wrote:
> Hello.
>
> I've encountered deadlock on postgresql 8.1. Here is the simple example.
>
> create table t1 (
> id1 integer primary key,
> val1 integer
> );
> create table t2 (
> id2 integer primary key,
> id1 integer references t1 on delete cascade,
> val1 integer,
> val2 integer,
> val3 integer
> );
> insert into t1 select
> generate_series(1,10) as id1;
> insert into t2 select
> generate_series(1,100) as id2,
> generate_series(1,10) as id1;
>
> Then three concurrent transaction start.
>
> /*1*/ begin;
> /*1*/ update t2 set val1=1 where id2=50;
> /*1*/ update t2 set val2=2 where id2=50;
> /*2*/ begin;
> /*2*/ update t2 set val1=1 where id2=40;
> /*2*/ update t2 set val2=2 where id2=40;
> /*2*/ commit;
> /*3*/ begin;
> /*3*/ update t1 set val1=1 where id1=10;
> /*1*/ update t2 set val3=3 where id2=50;
>
> Here we have deadlock for transactions 1 and 3.

That's not a deadlock, transaction 3 is simply waiting for transaction 1
to commit or rollback.

If you run a commit or rollback on transaction 1 then transaction 3 will
then be ready to commit or rollback as needed.

In response to

  • deadlock at 2007-04-09 09:24:04 from Alexey Nalbat

Browse pgsql-general by date

  From Date Subject
Next Message Thomas F. O'Connell 2007-04-12 20:34:16 Re: pg_standby
Previous Message Tom Lane 2007-04-12 20:30:10 Re: Evaluate only one CASE WHEN in a select