From: | Michael Meskes <meskes(at)postgresql(dot)org> |
---|---|
To: | PostgreSQL Hacker <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Deadlock? idle in transaction |
Date: | 2001-10-29 08:00:58 |
Message-ID: | 20011029090058.C1516@feivel.fam-meskes.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Oct 12, 2001 at 11:29:08AM -0700, Stephan Szabo wrote:
> Do you mean like task1 has gotten the A lock, and then task 2 gets the B
> and then task1 tries to get B and task2 tries to get A? I *think*
> (without ever looking at the code, and going on messages from here) that
> would probably kick off the deadlock alert since you're trying to grab
> a lock from a process which is waiting for a lock you hold.
I checked it and yes, it kicks off the deadlock alert. The idle in
transaction problem is not a deadlock but a transaction that simply does
not proceed.
In our case we believe to have found the reason. There was one user who
accessed the database via M$ Access and was allowed to write. And this user
looked into a table and then let this query open while doing other work.
Since he's able to change data I would guess that the query is internally
realized as a cursor select for update which of course locks. With Access
doing nothing but displaying the data the transaction certainly is idle.
That's it.
Michael
--
Michael Meskes
Michael(at)Fam-Meskes(dot)De
Go SF 49ers! Go Rhein Fire!
Use Debian GNU/Linux! Use PostgreSQL!
From | Date | Subject | |
---|---|---|---|
Next Message | Jean-Michel POURE | 2001-10-29 08:10:04 | Re: [HACKERS] Ultimate DB Server |
Previous Message | Jean-Michel POURE | 2001-10-29 07:50:36 | Re: Ultimate DB Server |