Re: Do we need so many hint bits? - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: Do we need so many hint bits?
Date
Msg-id 1353536416.11440.14.camel@sussancws0025
Whole thread Raw
In response to Re: Do we need so many hint bits?  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: MySQL search query is not executing in Postgres DB
Next
From: Jeff Janes
Date:
Subject: Re: tuplesort memory usage: grow_memtuples