From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> |
Cc: | Melvin Davidson <melvin6925(at)gmail(dot)com>, Mitu Verma <mitu(dot)verma(at)ericsson(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: duplicate key value violates unique constraint "pg_class_relname_nsp_index" |
Date: | 2015-05-27 14:30:44 |
Message-ID: | 31800.1432737044@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> writes:
> On 05/27/2015 06:05 AM, Melvin Davidson wrote:
>> What this indicates is that someone, or some thing, is trying to create
>> a table in a schema that already exists.
> The error you see in that situation is:
> postgres-2015-05-27 06:25:10.173 PDT-0ERROR: relation "table1" already
> exists
> postgres-2015-05-27 06:25:10.173 PDT-0STATEMENT: create table table1 (i
> int);
> Best guess is as Pete and Albe said, some user code is directly
> accessing pg_class or the index has been corrupted.
I don't think it's necessary to make such assumptions to explain the
errors. What is more likely is that two sessions are trying to create
identically named tables at about the same time. You do get the nice
user-friendly "already exists" error if the conflicting table was
committed before CREATE TABLE looks --- but in a concurrent-transactions
situation, neither CREATE TABLE will see the other's table as already
existing. In race conditions like this, it's the unique index on the
catalog that is the duplicate-preventer of last resort, and it's going
to throw this error.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2015-05-27 16:21:18 | Re: Reg: BULK COLLECT |
Previous Message | Andy Colson | 2015-05-27 13:43:12 | Re: Reg: BULK COLLECT |