Thread: creating the same table in 2 different sessions

Hi,

Maybe I found the following bug or 'not ideal behaviour'  of 
postgres(version 7.4.7 and 8.0 /linux):

first start asession 1

begin;

create table a0(a bigint);

than login for a second session

begin

create table a0(a bigint)

postgres block nows in session 2

when session 1  is commited the following error appears in session 2

duplicate key violates unique constraint "pg_class_relname_nsp_index"
So i think postgres first inserts into pg_class, but blocks in session 2 
because of the unique the unique index on (relname,relnamespace). I just 
wonder if it's safer to check if the table is being created in an other 
session, 'block' until the session is commited block before starting any 
insert or other action? Or when the error 'duplicate key violates unique 
constraint "pg_class_relname_nsp_index"' hapens during creating of a 
table ,raise  the error 'duplicate key violates unique constraint 
"pg_class_relname_nsp_index", maybe table allready exists' ?


Regards,
   Jeroen

Jeroen van Iddekinge <iddekingej@lycos.com> writes:
> begin;
> create table a0(a bigint);

> than login for a second session
> begin
> create table a0(a bigint)

> postgres block nows in session 2

> when session 1  is commited the following error appears in session 2

> duplicate key violates unique constraint "pg_class_relname_nsp_index"

It's always worked like that; certainly as far back as 7.0, which is the
oldest version I have alive to test.  The friendly "a0 already exists"
test falls through because a0 doesn't exist (at least it's not committed
at the time).  The unique index mechanism is the last-ditch fallback
that prevents the race condition from actually creating a problem.

So: no bug, it's operating as designed.  I agree that the error message
isn't as pretty as one might wish, but I don't think it's worth the
effort it would take to produce something else.  (The solution you
suggest doesn't fix it, it only makes the window narrower.)
        regards, tom lane