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