Skip site navigation (1) Skip section navigation (2)

Re: WIP -- renaming implicit sequences

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 (view raw or flat)
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!

In response to

pgsql-hackers by date

Next:From: Ants AasmaDate: 2012-01-21 10:51:55
Subject: Re: Re: Add minor version to v3 protocol to allow changes without breaking backwards compatibility
Previous:From: Kohei KaiGaiDate: 2012-01-21 09:28:33
Subject: Re: [v9.2] sepgsql's DROP Permission checks

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group