[tarantool-patches] Re: [PATCH v1 1/1] sql: fix tarantoolSqlite3TupleColumnFast

["n.pettik" <korablev@tarantool.org>]

> On 6 Dec 2018, at 12:17, Vladislav Shpilevoy <v.shpilevoy@tarantool.org> wrote:
> 
> On 06/12/2018 09:59, Kirill Shcherbatov wrote:
>> Hi! Thank you for research, I've included your conclusions to
>> the commit message.
>> The tarantoolSqlite3TupleColumnFast routine used to lookup
>> offset_slot in unallocated memory in some cases.
>> The assert with exact_field_count same as motivation to change
>> old correct assert with field_count in 7a8de28 is not correct.
>> assert(format->exact_field_count == 0 ||
>>        fieldno < format->exact_field_count);
>> The tarantoolSqlite3TupleColumnFast routine requires offset_slot
>> that has been allocated during tuple_format_create call. This
>> value is stored in indexed field with index that limited with
>> index_field_count that is <= field_count. Look at
>> tuple_format_alloc for more details.
>> The format in cursor triggering valid assertion has such
>> structure because first 4 tuples in _space: 257, 272, 276 and
>> 280 have an old format of _space with only one field
>> (format->field_count == 1).
>> It happens because these 4 tuples are recovered not after tuple
>> with id 280 which stores actual format of _space. After tuple
>> 280 is recovered, an actual format is set in struct space of
>> _space and all next tuples have full featured formats.
>> So for these 4 tuples tarantoolSqlite3TupleColumnFast can fail
>> even if a field exists, is indexed and has a name. Those
>> features are just described in a newer format.
>> (thank Gerold103 for problem explanation)
>> Closes #3772
> 
> LGTM. Nikita, please, review. Especially English part.

LGTM as well.