From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
---|---|
To: | Geoff Winkless <pgsqladmin(at)geoff(dot)dj> |
Cc: | Postgres General <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Transactional-DDL DROP/CREATE TABLE |
Date: | 2016-10-10 13:49:43 |
Message-ID: | CAHyXU0xLtYL_pMMuY+_f7KT5=WFxi_wobK_Rr3D9=0Q0nHGP5g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Thu, Oct 6, 2016 at 4:21 AM, Geoff Winkless <pgsqladmin(at)geoff(dot)dj> wrote:
> Hi
>
> I have code that does (inside a single transaction)
>
> DROP TABLE IF EXISTS mytable; CREATE TABLE mytable ....
>
> Occasionally this produces
>
> ERROR: duplicate key value violates unique constraint
> "pg_type_typname_nsp_index" DETAIL: Key (typname,
> typnamespace)=(mytable, 2200) already exists.
>
> I can get away from this by using CREATE TABLE IF NOT EXISTS in the
> same code, but there's the potential that the wrong data will end up
> in the table if that happens, and it also seems a little.... odd.
>
> Would you not expect this transaction to be atomic? ie at commit time,
> the transaction should drop any table with the same name that has been
> created by another transaction.
Transactions do not guarantee atomicity in the sense that you mean.
MVCC rules (which DDL generally fall under) try to interleave work as
much as possible which is the problem you're facing. What you want
is fully serialized creation which can be accomplished with advisory
lock or (better, imo) a leading
LOCK TABLE mytable;
Also, this is not a good pattern. You ought to be using temp tables
or other mechanics to store transaction local data.
merlin
From | Date | Subject | |
---|---|---|---|
Next Message | Periko Support | 2016-10-10 15:20:25 | Re: HA Cluster Solution? |
Previous Message | Moreno Andreo | 2016-10-10 12:25:31 | Re: How pg_dump works |