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