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
|
Список | 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 по дате отправления: