Re: Reduce lock levels for ADD and DROP COLUMN

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.

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.

regards, tom lane