From: | Oliver Jowett <oliver(at)opencloud(dot)com> |
---|---|
To: | Daniel Armbrust <daniel(dot)armbrust(at)comcast(dot)net> |
Cc: | pgsql-jdbc(at)postgresql(dot)org |
Subject: | Re: Problem dropping a table |
Date: | 2006-05-10 01:33:12 |
Message-ID: | 446142D8.10207@opencloud.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
Daniel Armbrust wrote:
> I tried 'setQueryTimeout' on the prepared statement, but
> it doesn't seem to have any effect. Still hangs indefinitely. Is
> setQueryTimeout implemented in the driver? I first posted on the
> regular mailing list, and Tom answered that the server should be
> supporting it.
I think that setQueryTimeout currently does nothing (it's just a hint
anyway, so this behaviour is legal -- it's just that noone has had time
to do a proper implementation).
You could manually execute a "set statement_timeout" query to get a
similar effect.
> The second, how can I track down what is locking this table? I presume that it is some of my code somewhere... maybe a prepared statement that I didn't get closed - but I can't find it. I've checked my code twice for any reference to this table, and every use of it is properly closing the result sets and the prepared statement. It seems like maybe the driver isn't releasing a lock when it is supposed to?
Merely having a prepared statement or resultset referencing the table
does not hold locks. The only thing that holds locks (AFAIK) is an open
transaction that did something requiring a lock. So perhaps you have an
open transaction on another connection that used the table but has not
yet called commit()/rollback(), or you have a concurrently executing
query that holds the lock?
-O
From | Date | Subject | |
---|---|---|---|
Next Message | Niels Beekman | 2006-05-10 11:38:52 | Release new driver version |
Previous Message | Patric Bechtel | 2006-05-10 01:05:52 | Re: Query length restriction in v3 protocol? |