Re: ALTER TABLE transaction isolation problem - Mailing list pgsql-general

From Kevin Grittner
Subject Re: ALTER TABLE transaction isolation problem
Date
Msg-id 1378222551.31427.YahooMailNeo@web162903.mail.bf1.yahoo.com
Whole thread Raw
In response to Re: ALTER TABLE transaction isolation problem  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: ALTER TABLE transaction isolation problem  (Kevin Grittner <kgrittn@ymail.com>)
List pgsql-general
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.  A REPEATABLE READ or SERIALIZABLE
transaction can currently see a table as completely empty, even if
it was not in that state at any point since the transaction began.
Heck, it can be seen in that state even if it was *never* visible
in that state -- for example, it was created with rows by SELECT
INTO and has never had all rows deleted or truncated since.

If an UPDATE modified the tuples you could never see things in such
an inconsistent state.

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: ALTER TABLE transaction isolation problem
Next
From: "ascot.moss@gmail.com"
Date:
Subject: Re: How to find out unused indexes?