Odd behaviour with redundant CREATE statement - Mailing list pgsql-performance

From Dave Crooke
Subject Odd behaviour with redundant CREATE statement
Date
Msg-id AANLkTikzdRv6hMH7z2zaGuQMuLvmUy-Wq7uVHfepQqsz@mail.gmail.com
Whole thread Raw
Responses Re: Odd behaviour with redundant CREATE statement
List pgsql-performance

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

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?

Cheers
Dave



pgsql-performance by date:

Previous
From: Robert Haas
Date:
Subject: Re: how to enforce index sub-select over filter+seqscan
Next
From: Gurjeet Singh
Date:
Subject: Re: Odd behaviour with redundant CREATE statement