Re: BUG #16763: CREATE TABLE IF NOT EXISTS fails with "relation exists"

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: BUG #16763: CREATE TABLE IF NOT EXISTS fails with "relation exists"
Дата
Msg-id 2169264.1607103006@sss.pgh.pa.us
обсуждение исходный текст
Ответ на BUG #16763: CREATE TABLE IF NOT EXISTS fails with "relation exists"  (PG Bug reporting form <noreply@postgresql.org>)
Ответы Re: BUG #16763: CREATE TABLE IF NOT EXISTS fails with "relation exists"  (Andy S <gatekeeper.mail@gmail.com>)
Список pgsql-bugs
PG Bug reporting form <noreply@postgresql.org> writes:
> Our application is run with a number of simultaneous instances each of them
> emits both DDL and DML to the DB.
> For example, at the very start they ensure base table structure exists so
> the emit queries like:
> CREATE TABLE IF NOT EXISTS tblname (...);
> During runtime they also emit queries to create new partitions to existing
> partitioned tables. Since both startup and/or runtime DDL could be emited
> simultaneously they suddenly are. This leads to errors like this:

> 2020-12-04 16:38:45.785 GMT [18814] ERROR:  relation
> "tblname_short_60_2657_3" already exists

IF NOT EXISTS doesn't attempt to be bulletproof: it just checks at the
start of the command to see if the object name is already there.  So
it's not sufficient to guard concurrent creations.  You can call that
a bug if you like, but it's quite unlikely to change anytime soon.

You might consider using advisory locks [1] to keep your various sessions
from trying to do this at the exact same time.

            regards, tom lane

[1] https://www.postgresql.org/docs/11/functions-admin.html#FUNCTIONS-ADVISORY-LOCKS



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

Предыдущее
От: PG Bug reporting form
Дата:
Сообщение: BUG #16763: CREATE TABLE IF NOT EXISTS fails with "relation exists"
Следующее
От: Andy S
Дата:
Сообщение: Re: BUG #16763: CREATE TABLE IF NOT EXISTS fails with "relation exists"