Re: WIP -- renaming implicit sequences

Поиск
Список
Период
Сортировка
От Thomas Munro
Тема Re: WIP -- renaming implicit sequences
Дата
Msg-id CADLWmXVTJDEbqMqyGr5LLZbkxgRQJUAKP9EUwpx53+kaYHVJzA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: WIP -- renaming implicit sequences  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On 19/01/2012, Robert Haas <robertmhaas@gmail.com> wrote:
> rhaas=# alter sequence foo_a_seq rename to bob;
> ALTER SEQUENCE
>
> If somebody renames the table or the column at this point, it's a good
> bet that they *don't* want bob renamed.

FWIW the patch addresses this case and wouldn't try to rename 'bob'.

> Another, admittedly minor consideration is that this can introduce
> some subtle concurrency bugs that we don't have today.  For example,
> suppose we choose a new name for the sequence which isn't in use, but
> then between the time when we pick the name and the time we do the
> insert the name becomes used, due to some concurrent transaction.  Now
> we'll fail with a rather baffling error message.  That isn't
> necessarily a huge problem - we have lots of code that is prone to
> such race conditions - but it's not wonderful either.  ...

I thought about this, and it seemed to me that (1) the same race
already applies when you CREATE a table with a serial column and (2)
anyone running a bunch of DDL concurrently with other DDL operations
already needs to coordinate their action or deal with occasional name
collisions in general.  But yeah I see that it's not ideal.

> I think we should remove this from the TODO list, or at least document
> that there are a number of reasons why it might be a deeper hole than
> it appears to be at first glance.

Fair enough, I'll leave it there.

Thanks for the feedback!


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

Предыдущее
От: Kohei KaiGai
Дата:
Сообщение: Re: [v9.2] sepgsql's DROP Permission checks
Следующее
От: Ants Aasma
Дата:
Сообщение: Re: Re: Add minor version to v3 protocol to allow changes without breaking backwards compatibility