Skip site navigation (1) Skip section navigation (2)

Re: Deadlock with tsearch2 index ...

From: "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Deadlock with tsearch2 index ...
Date: 2005-05-31 21:01:47
Message-ID: 20050531180026.I933@ganymede.hub.org (view raw or flat)
Thread:
Lists: pgsql-hackers
On Tue, 31 May 2005, Tom Lane wrote:

> "Marc G. Fournier" <scrappy(at)postgresql(dot)org> writes:
>> Just want to make sure that this is, in fact, what is expected:
>
>> client1: begin;
>> client1: update articles set some_col = <foo> where id = <bar>;
>> client2: update articles set some_col2 = <foo2> where id = <bar>;
>> client1: update articles set some_col3 = <foo> where id = <bar>;
>> client1: ** deadlock **
>
>> client2 can't finish its 'transaction', and is therefore preventing
>> client1 from continuing ... ?
>
> Hmm, I can see why client2 might be blocked by client1, but if client1
> holds the lock it should be able to continue to update the table.
>
> I take it from your title that this only happens if there's a tsearch2
> index on the table?  Can you put together a test case?

I haven't tried this myself, but the client wrote this very quick script 
that apparently recreates it every time:

test.sql:
---------------------------------------
/* load contrib/btree_gist.sql into database */

begin;

create table test (
  id serial primary key,
  age int
);
create index test_age_key on test using gist(age);

insert into test values (nextval('test_id_seq'), 1);

commit;

/*

client1:
begin; update test set age = 2 where id = 1;
client2:
update test set age = 2 where id = 1;
client1:
update test set age = 2 where id = 1;
...deadlock...

*/


----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy(at)hub(dot)org           Yahoo!: yscrappy              ICQ: 7615664

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2005-05-31 21:05:02
Subject: Re: Tablespace-level Block Size Definitions
Previous:From: Bricklen AndersonDate: 2005-05-31 21:01:13
Subject: Re: Tablespace-level Block Size Definitions

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group