On 09/04/18 18:21, Andrey Borodin wrote:
9 апр. 2018 г., в 19:50, Teodor Sigaev <teo...@sigaev.ru>
написал(а):
3. Why do we *not* lock the entry leaf page, if there is no
match? We still need a lock to remember that we probed for that
value and there was no match, so that we conflict with a tuple
that might be inserted later. At least #3 is a bug. The attached
patch adds an isolation test that demonstrates it. #1 and #2 are
weird, and cause unnecessary locking, so I think we should fix
those too, even if they don't lead to incorrect results.
I can't find a hole here. Agree.
Please correct me if I'm wrong. Let's say we have posting trees for
word A and word B. We are looking for a document that contains both.
We will read through all posting tree of A, but only through some
segments of B. If we will not find anything in B, we have to lock
only segments where we actually were looking, not all the posting
tree of B.
True, that works. It was not clear from the code or comments that that
was intended. I'm not sure if that's worthwhile, compared to locking
just the posting tree root block. I'll let Teodor decide..
BTW I do not think that we lock ranges. We lock possibility of
appearance of tuples that we might find. Ranges are shortcuts for
places where we were looking.. That's how I understand, chances are
I'm missing something.
Yeah, that's one way of thinking about it.
- Heikki
