Re: Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers
Дата
Msg-id CA+TgmobtSUBrmZUFdCy7+skeXe4686Ltr-mxCBMfHeNs-GmFsg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers  (Nikhil Sontakke <nikkhils@gmail.com>)
Ответы Re: Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers  (Nikhil Sontakke <nikhil.sontakke@enterprisedb.com>)
Список pgsql-hackers
On Thu, Nov 10, 2011 at 7:00 AM, Nikhil Sontakke <nikkhils@gmail.com> wrote:
> PFA, a patch against git head. We take the AccessShareLock lock on the
> schema in DefineRelation now. Note that we do not want to interlock with
> other concurrent creations in the schema. We only want to interlock with
> deletion activity. So even performance wise this should not be much of an
> overhead in case of concurrent DDL operations to the same schema.

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.

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

Вложения

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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Allow substitute allocators for PGresult.
Следующее
От: hubert depesz lubaczewski
Дата:
Сообщение: Re: [GENERAL] Strange problem with create table as select * from table;