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"
|
Список | 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 по дате отправления: