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>
Cc: pgsql-jdbc(at)postgresql(dot)org
Subject: Re: Problem dropping a table
Date: 2006-05-10 17:36:27
Message-ID: (view raw, whole thread or download thread mbox)
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 



Daniel Armbrust
Biomedical Informatics
Mayo Clinic Rochester

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-2017 The PostgreSQL Global Development Group