An error occurred while fetching folder content.
Vladimir Davydov
authored
Currently, vy_point_lookup(), in contrast to vy_read_iterator, doesn't rescan the memory level after reading disk, so if the caller doesn't track the key before calling this function, the caller won't be sent to a read view in case the key gets updated during yield and hence will be returned a stale tuple. This is OK now, because we always track the key before calling vy_point_lookup(), either in the primary or in a secondary index. However, for #2129 we need it to always return the latest tuple version, no matter if the key is tracked or not. The point is in the scope of #2129 we won't write DELETE statements to secondary indexes corresponding to a tuple replaced in the primary index. Instead after reading a tuple from a secondary index we will check whether it matches the tuple corresponding to it in the primary index: if it is not, it means that the tuple read from the secondary index was overwritten and should be skipped. E.g. suppose we have the primary index over the first field and a secondary index over the second field and the following statements in the space: REPLACE{1, 10} REPLACE{1, 20} Then reading {10} from the secondary index will return REPLACE{1, 10}, but lookup of {1} in the primary index will return REPLACE{1, 20} which doesn't match REPLACE{1, 10} read from the secondary index hence the latter was overwritten and should be skipped. The problem is in the example above we don't want to track key {1} in the primary index before lookup, because we don't actually read its value. So for the check to work correctly, we need the point lookup to guarantee that the returned tuple is always the newest one. It's fairly easy to do - we just need to rescan the memory level after yielding on disk if its version changed. Needed for #2129
Name | Last commit | Last update |
---|