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

Re: Reduce lock levels for ADD and DROP COLUMN

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Reduce lock levels for ADD and DROP COLUMN
Date: 2010-12-27 19:51:43
Message-ID: 1293479503.1193.65345.camel@ebony (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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 
 PostgreSQL Development, 24x7 Support, Training and Services

In response to

pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2010-12-27 20:03:55
Subject: Re: C++ keywords in headers (was Re: [GENERAL] #include <funcapi.h>)
Previous:From: Peter GeogheganDate: 2010-12-27 19:48:50
Subject: Re: C++ keywords in headers (was Re: [GENERAL] #include <funcapi.h>)

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