Jeroen van Iddekinge <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
