Re: rewrite of RECENTLY DEAD tuples

Поиск
Список
Период
Сортировка
От Noah Misch
Тема Re: rewrite of RECENTLY DEAD tuples
Дата
Msg-id 20110217173523.GA13194@tornado.leadboat.com
обсуждение исходный текст
Ответ на rewrite of RECENTLY DEAD tuples  ("Benjamin S." <da_joind@gmx.net>)
Список pgsql-hackers
On Thu, Feb 17, 2011 at 09:38:51AM +0100, Benjamin S. wrote:
> ATRewriteTable in tablecmds.c uses SnapshotNow to rewrite and thus
> does not copy RECENTLY DEAD tuples. But copy_heap_data in cluster.c
> uses SnapshotAny and copys RECENTLY DEAD tuples to the new heap
> file.
> 
> I don't understand why it is not needed in the first case. In the
> second case I guess that there may be still a transaction with an
> older snapshot running which should be able to open the rewrited
> table and see the older (RECENTLY DEAD) tuple. Why must a
> transaction in the first case not be able to do so also?

Unlike VACUUM FULL and CLUSTER, ALTER TABLE rewrites are not MVCC-safe.  No
visibility-relevant information is preserved; all tuples get the xmin of the
ALTER TABLE transaction.  The table will look empty to snapshots predating the
commit of the ALTER TABLE transaction.  Compare TRUNCATE.

All other things being equal, it would be nice for ALTER TABLE rewrites to
become MVCC-safe.  The main implication is that tuples not visible to us can
cause the operation to fail.  Example:

CREATE TABLE t (x int);
CREATE DOMAIN int_notnull AS int NOT NULL;
INSERT INTO t VALUES (NULL);
-- acquire a snapshot in some other session here
DELETE FROM t;
ALTER TABLE t ALTER x TYPE int_notnull; -- error converting deleted tuple

If we also made the error message sufficiently informative, I'd wager this would
be a net improvement for the average user.

Thanks,
nm


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: Debian readline/libedit breakage
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: patch (for 9.1) string functions ( correct patch attached )