Simon Riggs <si...@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. 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers