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

[Vladislav Shpilevoy]

On 05/12/2018 23:41, Kirill Shcherbatov wrote:
>> In which 'some'? Yes, assert is wrong, but I do not understand
>> how is it possible that fieldno >= field_count if such errors
>> are caught during parsing stage.
> Please, read commit message referenced by my ticket 7a8de28.

It should be written in this commit message. Message in 7a8de28
is wrong.

> 
> kyukhin wrote:
> "This assert is not always hold, e.g. for _schema space where max_id
>    is stored behind formatted fields."
> about redefined to invalid assert
> 

max_id has nothing to do with the problem. From SQL it is impossible to
select not named fields.

The problem is that 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.

Moreover, even on these tuples a memory lookup is not always dirty. This
request fails:

	box.sql.execute("SELECT \"name\" FROM \"_space\"")

But these do not:

	box.sql.execute("SELECT \"name\" FROM \"_space\" WHERE \"id\" < 258")
	box.sql.execute("SELECT \"name\" FROM \"_space\" WHERE \"id\" = 272")
	box.sql.execute("SELECT \"name\" FROM \"_space\" WHERE \"id\" = 276")

For an unknown reason the latters do not lookup 'name' field via
tarantoolSqlite3TupleColumnFast. Looks like a strange behaviour of
the planner. But this is another issue.