Re: Problem dropping a table

Поиск
Список
Период
Сортировка
От Oliver Jowett
Тема Re: Problem dropping a table
Дата
Msg-id 446142D8.10207@opencloud.com
обсуждение исходный текст
Ответ на Problem dropping a table  (Daniel Armbrust <daniel.armbrust@comcast.net>)
Ответы Re: Problem dropping a table  (Dan Armbrust <daniel.armbrust.list@gmail.com>)
Список 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
aprepared statement that I didn't get closed - but I can't find it.  I've checked my code twice for any reference to
thistable, and every use of it is properly closing the result sets and the prepared statement.  It seems like maybe the
driverisn'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

В списке pgsql-jdbc по дате отправления:

Предыдущее
От: Patric Bechtel
Дата:
Сообщение: Re: Query length restriction in v3 protocol?
Следующее
От: "Niels Beekman"
Дата:
Сообщение: Release new driver version