Dan Armbrust wrote:
> Oliver Jowett wrote:
>> 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?
Thanks for your tip, I finally stopped looking in all the wrong places,
and found the problem.
In order to stream a large result set, I had called setAutoCommit(false)
in one portion of the code. The code that was supposed to turn
autocommit back on was not being called - hence, I had a transaction
that was hung open. The only remaining oddity is that the open
transaction was preventing me from removing a table that I never
accessed in the transaction...
Anyway, I finally got everything working the way it is supposed to on my
Mayo Clinic Rochester
In response to
pgsql-jdbc by date
|Next:||From: Kris Jurka||Date: 2006-05-10 17:40:33|
|Subject: Re: backwards compatibility problem|
|Previous:||From: Mark Lewis||Date: 2006-05-10 16:33:11|
|Subject: Re: Query length restriction in v3 protocol?|