Re: Do we need so many hint bits?
От | Jeff Davis |
---|---|
Тема | Re: Do we need so many hint bits? |
Дата | |
Msg-id | 1353536416.11440.14.camel@sussancws0025 обсуждение исходный текст |
Ответ на | Re: Do we need so many hint bits? (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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
В списке pgsql-hackers по дате отправления: