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: Oliver Jowett <oliver(at)opencloud(dot)com>
Cc: pgsql-jdbc(at)postgresql(dot)org
Subject: Re: Problem dropping a table
Date: 2006-05-10 14:43:35
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-jdbc
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

Well, thats good (but utterly confusing to me) to know... I'm not 
running any transactions, and nothing else is going on concurrently that 
I'm aware of.  But it gives me a new direction to go hunting in.  I've 
certainly spent enough time checking for unclosed resultsets and 
prepared statements.  I know that the lock is being held by my code, I 
just don't know where.  Funny thing is, this code is written to work on 
multiple databases - and I don't have any issues at all on DB2, MySQL, 
Oracle, MSAccess, or Hypersonic DB.  Just Postgres, in this one set of 
queries.  Which is starting to make me think I've uncovered a driver 
bug...  I'm going to spend more time today trying to figure out which 
exact query of mine is establishing the lock.


Daniel Armbrust
Biomedical Informatics
Mayo Clinic Rochester

In response to


pgsql-jdbc by date

Next:From: Csaba NagyDate: 2006-05-10 16:27:46
Subject: backwards compatibility problem
Previous:From: Mads N. VestergaardDate: 2006-05-10 12:48:56
Subject: Re: Problem loading driver

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