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@Fam-Meskes.De
Go SF 49ers! Go Rhein Fire!
Use Debian GNU/Linux! Use PostgreSQL!
