Re: Reduce lock levels for ADD and DROP COLUMN

On Mon, 2010-12-27 at 13:33 -0500, Tom Lane wrote:
> Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> > Do you disagree with the ADD or the DROP, or both?
>
> Both.
>
> > What "stuff" will break, in your opinion? I'm not asking you to do the
> > research, but a few curveballs would be enough to end this quickly, and
> > leave a good record for the archives.
>
> The most obvious point is that the parser, planner, and executor
> all depend on the assumption that the lock originally taken in
> parserOpenTable() is sufficient to ensure that the table definition
> isn't moving underneath them. It will not be good if the executor
> sees a different table definition than the parser saw.

> To give just one concrete example of what's likely to go wrong, when we
> read pg_attribute to construct the table's tuple descriptor, we do so
> with SnapshotNow. If someone commits a change to one of those
> pg_attribute rows while that scan is in progress, we may see both or
> neither version of that pg_attribute row as valid.

That sounds like a big problem.

> I believe there are more subtle assumptions associated with the fact
> that the relcache keeps a copy of the table's tupledesc; various places
> assume that the cached tupdesc won't change or disappear underneath them
> as long as they've got some lock on the table.

Thanks for explaining.

At this stage of 9.1, I will immediately stop pursuing this possibility.

This is an important area for us for the future, since crowds gather
over RDBMS' collective inability to add/drop new attributes easily.

--
Simon Riggs http://www.2ndQuadrant.com/books/
PostgreSQL Development, 24x7 Support, Training and Services