Vatsal Avasthi <vatsal.avasthi@wipro.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
