Kevin Grittner <kgrittn@xxxxxxxxx> wrote: > Tom Lane <tgl@xxxxxxxxxxxxx> wrote: >> Kevin Grittner <kgrittn@xxxxxxxxx> writes: >>> Why don't we rewrite tuples with their existing xid in such >>> cases? The current state of affairs seem to me to be a pretty >>> clear bug. >> >> No, it isn't --- the tuple is being modified by the ALTER >> command. > > If a REPEATABLE READ or SERIALIZABLE transaction cannot see the > state of a table as of the point it took its snapshot, that is a > bug. There are reasonable arguments why the right fix isn't to > keep the same xmin value, but that doesn't make the current > situation less of a bug. It seems to me that the only truly correct way to handle this would be for a REPEATABLE READ or SERIALIZABLE transaction to see the table definition which matches its snapshot, and access the indexes and heap which correspond to that. Would the new MVCC access to catalogs support such an extreme change? Next best would be to recognize that the relation is not in a state which matches the snapshot and throw an error. After that it's a question of whether it's better to see and try to use the right number of rows with possibly the wrong columns or the wrong values (i.e., possibly correct, but possibly wrong in a way that's hard to notice) or to see zero rows with possibly the wrong columns (i.e., the results may be more likely to be wrong and more obviously wrong if a human is looking at them). That's a choice between two bad options, either of which could silently return incorrect data, so I hope we can fix this by making it correct or by throwing an error. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
