Re: Transactional-DDL DROP/CREATE TABLE

Поиск
Список
Период
Сортировка
От Francisco Olarte
Тема Re: Transactional-DDL DROP/CREATE TABLE
Дата
Msg-id CA+bJJbwdjA_vWWdB+Co3fwmoJ5i3GhmzjJt164hUH+ZGHTEchA@mail.gmail.com
обсуждение исходный текст
Ответ на Transactional-DDL DROP/CREATE TABLE  (Geoff Winkless <pgsqladmin@geoff.dj>)
Ответы Re: Transactional-DDL DROP/CREATE TABLE  (Geoff Winkless <pgsqladmin@geoff.dj>)
Список pgsql-general
On Thu, Oct 6, 2016 at 11:21 AM, Geoff Winkless <pgsqladmin@geoff.dj> wrote:
> 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.

It seems to be atomic, either it drop/creates or does nothing. What
you want is a beyond atomicity. What does the other transaction do?
What if the other transaction hasn't commited? or it has created the
table anew ( no drop, the table wasn't there ). What are the isolation
levels involved?

If all the transactions operating in the table are doing just what you
show an nothing more, and they are all serializable, I MAY expect
that, but wouldn't put much money in it.

Francisco Olarte.


В списке pgsql-general по дате отправления:

Предыдущее
От: Aleksander Alekseev
Дата:
Сообщение: Re: ZSON, PostgreSQL extension for compressing JSONB
Следующее
От: Geoff Winkless
Дата:
Сообщение: Re: Transactional-DDL DROP/CREATE TABLE