From: | Thomas Munro <munro(at)ip9(dot)org> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: WIP -- renaming implicit sequences |
Date: | 2012-01-21 10:14:47 |
Message-ID: | CADLWmXVTJDEbqMqyGr5LLZbkxgRQJUAKP9EUwpx53+kaYHVJzA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 19/01/2012, Robert Haas <robertmhaas(at)gmail(dot)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!
From | Date | Subject | |
---|---|---|---|
Next Message | Ants Aasma | 2012-01-21 10:51:55 | Re: Re: Add minor version to v3 protocol to allow changes without breaking backwards compatibility |
Previous Message | Kohei KaiGai | 2012-01-21 09:28:33 | Re: [v9.2] sepgsql's DROP Permission checks |