Re: Deadlock problem

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Vatsal Avasthi <vatsal(dot)avasthi(at)wipro(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org, sszabo(at)megazone(dot)bigpanda(dot)com, alvherre(at)dcc(dot)uchile(dot)cl
Subject: Re: Deadlock problem
Date: 2003-10-30 22:49:49
Message-ID: 3645.1067554189@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Vatsal Avasthi <vatsal(dot)avasthi(at)wipro(dot)com> writes:
> I am using postgres version 7.2.1.

> Looks like both try to have a lock and that leads to a deadlock
> situation.

It's hard to believe that SELECT and DROP TRIGGER alone could deadlock;
and if they did, you should get a deadlock failure report, not an
indefinite wait. I think more likely the situation is that some third
client process is holding open a transaction that has some kind of lock
on the table. DROP TRIGGER would then block waiting for that process
(since it needs to get exclusive lock on the table). And then, fresh
SELECTs (or anything else) would stack up behind the DROP TRIGGER. This
is not a deadlock though, just everyone waiting for the original lock
holder to get off his duff and do something.

If you are unconvinced, I would recommend updating to 7.3.4 or 7.4beta
so that you can get more information by looking at the pg_locks system
view. It's difficult to tell what's happening in 7.2 or older.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message ohp 2003-10-30 22:59:25 Re: Please help
Previous Message Tom Lane 2003-10-30 22:34:14 Re: CREATE TYPE for case insensitive text and varchar