Re: Reduce lock levels for ADD and DROP COLUMN - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Reduce lock levels for ADD and DROP COLUMN
Date
Msg-id 1293479503.1193.65345.camel@ebony
Whole thread Raw
In response to Re: Reduce lock levels for ADD and DROP COLUMN  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, 2010-12-27 at 13:33 -0500, Tom Lane wrote:
> Simon Riggs <simon@2ndQuadrant.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



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: C++ keywords in headers (was Re: [GENERAL] #include )
Next
From: Alvaro Herrera
Date:
Subject: Re: C++ keywords in headers (was Re: [GENERAL] #include )