Re: Tuple visibility within a single XID

From: Qingqing Zhou <zhouqq(dot)postgres(at)gmail(dot)com>
To: Peter Geoghegan <pg(at)heroku(dot)com>
Cc: Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Tuple visibility within a single XID
Date: 2015-04-08 02:16:43
Message-ID: CAJjS0u3_WG0JENwQ6MNFGXsWSj=fnPtma9ry_qmzZhorw1t-kw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Apr 7, 2015 at 6:11 PM, Peter Geoghegan <pg(at)heroku(dot)com> wrote:
> No. For one thing, unique index enforcement still requires the tuples
> to be treated as a conflict while the other transaction is running
> IMV.
>

Not sure if I understand correctly: in uniqueness check, we see all
possible tuples with a dirty snapshot. For a tuple version inserted
and updated by myself, it is surely dead no matter how the transaction
ends. So I interpret that we can safely pruning the version.

Early pruning may cause some behavior change though. For example, here is a T1:

begin;
-- loop the following statements many times
insert into pk values (1); -- uniqueness defined
delete from pk;
abort;

If another transaction T2 coming later than T1, and if we prune early,
then T1 can suddenly hang on insertion waiting for T2 to complete. But
does this violate any isolation rule?
Thanks,
Qingqing

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2015-04-08 02:16:48 Re: pg_rewind and log messages
Previous Message Michael Paquier 2015-04-08 02:02:32 Re: pg_regress writes into source tree