Re: Reduce lock levels for ADD and DROP COLUMN
От | Simon Riggs |
---|---|
Тема | Re: Reduce lock levels for ADD and DROP COLUMN |
Дата | |
Msg-id | 1293479503.1193.65345.camel@ebony обсуждение исходный текст |
Ответ на | Re: Reduce lock levels for ADD and DROP COLUMN (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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 по дате отправления: