Re: Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers
Дата
Msg-id CA+TgmobUkuuUx9vQN7Rz+kz-sA8R0zKAhvEXTD6rs0N51zqW6A@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  (Alvaro Herrera <alvherre@commandprompt.com>)
Список pgsql-hackers
On Mon, Nov 14, 2011 at 12:48 PM, Nikhil Sontakke <nikkhils@gmail.com> wrote:
>> So it's probably going to take a while to get this
>> completely nailed down, but we can keep chipping away at it.
>
> Agreed. So are you planning to commit this change? Or we want some more
> objects to be fixed? Last I looked at this, we will need locking to be done
> while creating tables, views, types, sequences, functions, indexes,
> extensions, constraints, operators stuff, ts stuff, rules, domains, etc.
> that can go into schemas.

<reads the code>

Well, it looks to me like there are three different places that we
need to nail down: RangeVarGetAndCheckCreationNamespace() is used for
relations (except that a few places call RangeVarGetCreationNamespace
directly, which means my previous patch probably needs some tweaking
before commit), QualifiedNameGetCreationNamespace() is used for pretty
much all other schema-qualified objects, and LookupCreationNamespace()
is used for ALTER BLAH SET SCHEMA (which I think has a problem when
you rename an object into a schema that is concurrently being
dropped).

I'm fairly unhappy with the idea of modifying a function that is
described as doing a "get" or "lookup" to have the side effect of
"locking something".  So probably some renaming or refactoring is in
order here.  It seems like we're duplicating almost identical logic in
an awful lot of places in namespace.c.

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


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Cause of intermittent rangetypes regression test failures
Следующее
От: Greg Stark
Дата:
Сообщение: Re: So where are we on the open commitfest?