Re: Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers

Поиск
Список
Период
Сортировка
От Nikhil Sontakke
Тема Re: Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers
Дата
Msg-id CABamaqMtYeRuciHtqQgk47nfFPuUO7XoeuVUjtkfUq0zNEnvKA@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

 
If all you need to do is lock a schema, you can just call
LockDatabaseObject(NamespaceRelationId, namespace_oid, 0,
AccessShareLock); there's no need to fake up an objectaddress just to
take a lock.  But I think that's not really all you need to do,
because somebody could drop the namespace between the time that you
decide what OID to lock and the time you acquire the lock.  So I think
you need something like what we did in RangeVarGetRelid().  See
attached patch.


Thanks Robert. But currently there are very few callers of RangeVarGetAndCheckCreationNamespace() function. For the sake of completeness we will have to introduce a call to this function while creating all other objects too.

Regards,
Nikhils
 
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

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

Предыдущее
От: Nikhil Sontakke
Дата:
Сообщение: Re: So where are we on the open commitfest?
Следующее
От: Emanuel Calvo
Дата:
Сообщение: Re: [Feature Request] \dx show "options"