Kevin Grittner <kgrittn@ymail.com> wrote:
> Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Kevin Grittner <kgrittn@ymail.com> 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
