On Mon, Nov 28, 2016 at 4:50 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>
> Well, my original email did contain a discussion of the need for
> delete-marking. I said that you couldn't do in-place updates when
> indexed columns were modified unless the index AMs had support for
> delete-marking, which is the same point you are making here.
>
Sorry, I had not read that part earlier, but now that I read it, I
think there is a slight difference in what I am saying. I thought
along with delete-marking, we might need transaction visibility
information in the index as well. BTW, it is not completely clear
whether you want a delete-marking system or you think we could do
without that by avoiding in-place updates, it seems to me from what
you have written that you are inclined towards having a delete-marking
system.
> However,
> I agree that the case where the indexed column gets set back to a
> previous value while the old index tuple for that value still exists
> is particularly tricky. I think that what we need to do there is
> avoid inserting an index entry for a given value/TID pair if an index
> entry for that value/TID pair already exists.
>
Are you saying this for indexes with a delete-marking system or for
indexes without that or for both?
> That's a little different from your analysis. In your step-3
> analysis, you say that an index scan for 2 will find the step-1 tuple,
> but that's not really right. The index scan will find the index tuple
> which points to the whole chain of tuples, step-3 => step-2 => step-1,
> and it will decide which heap tuple from that chain the user can see
> based on the user's snapshot.
>
I think the scan will not traverse the chain if it starts after
step-3's commit and that's what I intend to say.
> That's OK, but we're in real trouble if
> step-3 inserted an additional index tuple pointing to that chain
> rather than simply noting that one already exists. If it adds an
> additional one, then we'll visit two index tuples for that TID. Each
> time, the visibility information in UNDO will cause us to return the
> correct tuple, but we've erred by returning it twice (once per index
> entry) rather than just once.
>
Why will scan traverse the UNDO chain if it starts after step-3 commit?
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com