Re: Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers

Поиск
Список
Период
Сортировка
От Nikhil Sontakke
Тема Re: Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers
Дата
Msg-id CANgU5Zc4D6VSihpWx7guvE_SPHzbZr9Vr2oFBd3Pr+sLrYpZEw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers

 
> We definitely need some interlocking to handle this. For lack of better
> APIs, we could do a LockDatabaseObject() call in AccessShareLock mode on the
> namespace and release the same on completion of the creation of the object.
>
> Thoughts?

In general, we've been reluctant to add locking on non-table objects
for reasons of overhead.  You can, for example, drop a type or
function while a query is running that depends on it (which is not
true for tables).  But I think it is sensible to do it for DDL
commands, which shouldn't be frequent enough for the overhead to
matter much.  

Agreed. Especially if the race condition has non-trivial downsides as mentioned in the tablespace case.
 
When I rewrote the comment code for 9.1, I added locking
that works just this way, to prevent pg_description entries from being
orphaned; see the end of get_object_address().


Yeah thanks, that does the object locking. For pre-9.1 versions, we will need a similar solution. I encountered the issue on 8.3.x..

Regards,
Nikhils

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

Предыдущее
От: Jaime Casanova
Дата:
Сообщение: Re: Syntax for partitioning
Следующее
От: Tom Lane
Дата:
Сообщение: Re: a modest improvement to get_object_address()