On Mon, Sep 27, 2010 at 8:50 PM, Dave Crooke <dcro...@gmail.com> wrote:
> > Our Java application manages its own schema. Some of this is from > Hibernate, but some is hand-crafted JDBC. > > By way of an upgrade path, we have a few places where we have added > additional indexes to optimize performance, and so at startup time the > application issues "CREATE INDEX ..." statements for these, expecting to > catch the harmless exception "ERROR: relation "date_index" already exists", > as a simpler alternative to using the meta-data to check for it first. > > In general, this seems to work fine, but we have one installation where we > observed one of these CREATE statements hanging up in the database, as if > waiting for a lock, thus stalling the app startup You can tell if it is really waiting by looking at 'select * from pg_locks', and check the 'granted' column. > it's PG 8.4.4 64-bit on RHEL 5, installed with the postgresql.org YUM > repository. > > Stopping and restarting PG did not clear the issue. While this is going on, > the database is otherwise responsive, e.g. to access with psql. > Also check if you have any prepared transactions waiting to be committed or rolled back. select * from pg_prepared_xacts > > Is this "expected failure" considered a dangerous practice in PGSQL and > should we add checks? > > Does the hangup indicate a possible corruption problem with the DB? > Very unlikely. Regards, -- gurjeet.singh @ EnterpriseDB - The Enterprise Postgres Company http://www.EnterpriseDB.com singh.gurj...@{ gmail | yahoo }.com Twitter/Skype: singh_gurjeet Mail sent from my BlackLaptop device
