I'll add a test a bit later.

Very interesting...

I couldn't construct small functional test on which this bug reproduces, because it will require knowledge of too many implementation details. But it reproduces in case like this:

CREATE TABLE test_table
(
    `date` Date,
    `timestamp` UInt32,
    `host` String,
    `http_code` UInt16,
    `test_id` Array(Int32)
)
ENGINE = MergeTree(date, (timestamp, host, http_code), 8192)

There is one detail of data in the table: column test_id has huge ranges in which all arrays are empty.

SELECT *
FROM test_table
WHERE (date = '2022-01-16') AND (host = 'some_host.com') AND (test_id = [3333])
ORDER BY timestamp DESC
LIMIT 100
SETTINGS optimize_read_in_order = 1

In this query we read data in the reverse order of primary key. Assume that while reading we made a seek by the default path. We have some data in buffer from previous calls at this moment and as it written in comment we delay fetching new data to the buffer to the next call of nextImpl . Then it happens that we are reading granule in which all arrays are empty and it will lead to call of readBig with n=0 in reading of array elements. Since n=0 we won't call any reading and nextImpl won't be triggered as we had expected. Then on next call of seek to the position, which is a bit bellow current position (remember that we are reading ranges backwards) this check will pass and we will move position in buffer without actual seek, but actually buffer contains wrong data.

In other words - when we read zero bytes after seek, we don't change the buffer contents, but it becomes inconsistent with the position in file?

Maybe we can reset buffer to zero when we read zero bytes at the different offset?

Need to check other buffers that allow seeks?

@Mergifyio rebase

rebase

✅ Branch has been successfully rebased

Sorry but I cannot resist to merge it.

@alexey-milovidov

Maybe we can reset buffer to zero when we read zero bytes at the different offset?

It's hard because there are two different buffers: CompressedReadBuffer and ReadBufferFromFileDescriptor and when we request to read zero bytes from CompressedReadBuffer we can't easily and safely reset buffer of ReadBufferFromFileDescriptor, which is used by CompressedReadBuffer. Anyway, I think that is should be possible to do several consecutive seeks, because such situation may appear in other circumstantiates, not only while reading zero bytes.

Need to check other buffers that allow seeks?

Yes, it's worth to check.