Re: ALTER TABLE transaction isolation problem

From: Kevin Grittner <kgrittn(at)ymail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: DT <kurt023(at)hotmail(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: ALTER TABLE transaction isolation problem
Date: 2013-09-03 15:35:51
Message-ID: 1378222551.31427.YahooMailNeo@web162903.mail.bf1.yahoo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Kevin Grittner <kgrittn(at)ymail(dot)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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message ascot.moss@gmail.com 2013-09-03 15:48:05 Re: How to find out unused indexes?
Previous Message Tom Lane 2013-09-03 15:01:57 Re: ALTER TABLE transaction isolation problem