Re: Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers
Дата
Msg-id CA+TgmobsLfb2w_MDsap=GzAEqdADSf7RfRQ406yVQQaPNMJ+_w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers  (Nikhil Sontakke <nikhil.sontakke@enterprisedb.com>)
Ответы Re: Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers  (Nikhil Sontakke <nikkhils@gmail.com>)
Список pgsql-hackers
On Mon, Nov 14, 2011 at 11:48 AM, Nikhil Sontakke
<nikhil.sontakke@enterprisedb.com> wrote:
>> 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.

Well, RangeVarGetAndCheckCreationNamespace is only (and can only) be
used for relations.  To get similar protection for other object types,
we'd need to add a similar logic elsewhere.  I haven't looked at where
it would need to go.

In fact, I think that the technique demonstrated here (which was
pioneered by Noah Misch) is actually quite general, and there are
probably a lot of places where we need to be doing it but currently
are not.  So it's probably going to take a while to get this
completely nailed down, but we can keep chipping away at it.

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


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

Предыдущее
От: Emanuel Calvo
Дата:
Сообщение: Re: [Feature Request] \dx show "options"
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Regression tests fail once XID counter exceeds 2 billion