Re: Problem dropping a table

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

In response to

Responses

Browse pgsql-jdbc by date

  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?