Skip site navigation (1) Skip section navigation (2)

Re: Problem dropping a table

From: Dan Armbrust <daniel(dot)armbrust(dot)list(at)gmail(dot)com>
To:
Cc: pgsql-jdbc(at)postgresql(dot)org
Subject: Re: Problem dropping a table
Date: 2006-05-10 17:36:27
Message-ID: 4462249B.6050304@gmail.com (view raw or flat)
Thread:
Lists: pgsql-jdbc
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?
>>
>> -O
>>
> 

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 
end.

Thanks,

Dan


-- 
****************************
Daniel Armbrust
Biomedical Informatics
Mayo Clinic Rochester
daniel.armbrust(at)mayo.edu
http://informatics.mayo.edu/

In response to

pgsql-jdbc by date

Next:From: Kris JurkaDate: 2006-05-10 17:40:33
Subject: Re: backwards compatibility problem
Previous:From: Mark LewisDate: 2006-05-10 16:33:11
Subject: Re: Query length restriction in v3 protocol?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group