Re: Do we need so many hint bits?
Jeff Davis <pgsql@j-davis.com>
From: Jeff Davis <pgsql@j-davis.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Atri Sharma <atri.jiit@gmail.com>, Andres Freund <andres@2ndquadrant.com>, Pg Hackers <pgsql-hackers@postgresql.org>, Merlin Moncure <mmoncure@gmail.com>
Date: 2012-11-21T22:20:16Z
Lists: pgsql-hackers
On Mon, 2012-11-19 at 14:46 -0500, Tom Lane wrote: > Jeff Davis <pgsql@j-davis.com> writes: > > As I said elsewhere in the thread, I'm not planning to introduce any > > additional locking. There is already precedent in IndexOnlyNext. > > Of course, that just begs the question of whether the code in > IndexOnlyNext is correct. And after looking at it, it seems pretty > broken, or at least the argument for its correctness is broken. > That comment seems to consider only the case where the target tuple has > just been inserted --- but what of the case where the target tuple is in > process of being deleted? The deleter will not make a new index entry > for that. Of course, there's a pretty long code path from marking a > tuple deleted to committing the deletion, and it seems safe to assume > that the deleter will hit a write barrier in that path. But I don't > believe the argument here that the reader must hit a read barrier in > between. After digging in a little, this is bothering me now, too. I think it's correct, and I agree with your analysis, but it seems a little complex to explain why it works. It also seems like a fortunate coincidence that we can detect clearing the bit due to an insert, which we need to know about immediately; but not detect a delete, which we don't care about until it commits. I will try to update the comment along with my submission. Regards, Jeff Davis