Tom Lane-2 wrote
>> 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.
>
> regards, tom lane
I'm not quite sure what exactly you are referring to. I agree the behavior
of "ALTER TABLE" is not buggy but the fact that it is not documented as
being MVCC-unsafe (like truncate; sometimes) is a documentation
bug/oversight.
If that is the extent of your comment then we'd still like to hear what you
think of the larger issue that a SERIALIZABLE transaction will not fail in
the presence of an ALTER TABLE command issued during the lifetime of the
transaction.
This does appear to be a bug and since the only way to return the original
data would be to have two copies of the table in memory for an indefinite
time period it makes more sense to use catalog versioning to detect when
table structure has altered and cause the transaction to fail.
It is too dangerous, given the wide variety of alterations possible using
ALTER TABLE, for these transactions - if begun before the ALTER TABLE - to
reference the altered table. The status-quo, if documented, is always an
option - especially since the exposure size on this is fairly small - but
the only reason not to correct it and throw an error would be if the checks
needed to do so are too expensive.
David J.
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/ALTER-TABLE-transaction-isolation-problem-tp5769289p5769461.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.
