On Mon, Nov 28, 2016 at 4:50 AM, Robert Haas <robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers