Hello! It seems I have managed to produce a segfault in my ClickHouse server.

I have a table that looks like this:
```
CREATE TABLE test_table (
	"column_1" String NOT NULL,
	"column_2" LowCardinality(String) NOT NULL,
	"column_3" LowCardinality(String) NOT NULL,
	"timestamp" Datetime64(6) NOT NULL
)
ENGINE = AggregatingMergeTree()
PARTITION BY toYYYYMM("timestamp")
PRIMARY KEY ("column_1", "column_2", "timestamp", "column_3")
;
```

Then I run a query that looks likes this
```
SELECT max(timestamp) FROM (
	SELECT timestamp, column_1, column_2, column_3
	FROM test_table
	ORDER BY timestamp asc
	LIMIT 1500
)
```

Next, 3 strange things happen:
1. I am a getting a different result timestamp every time I run this query (no data is being inserted into the table and I ran OPTIMIZE FINAL earlier to make sure no merging is happening in the background)
2. If I change the limit to anything below 1500 (even 1499) the problem disappears.
3. When testing this query on my production server that has a lot other queries running on it at the same time I managed to crash the server and I got a stack trace that looks like this
```
2022.09.08 09:20:56.777322 [ 2857169 ] {} <Fatal> BaseDaemon: ########################################
2022.09.08 09:20:56.777425 [ 2857169 ] {} <Fatal> BaseDaemon: (version 22.6.2.12 (official build), build id: 52AFD84A0FEDD1BA) (from thread 2857119) (query_id: c94aa1c3-4b1e-4d34-a35a-a94c22d7e3ea) (query: select max(timestamp) from ( SELECT timestamp, column_1, column_2, column_3 FROM test_table
 order by timestamp asc, id asc limit 1500 )) Received signal Segmentation fault (11)
2022.09.08 09:20:56.777461 [ 2857169 ] {} <Fatal> BaseDaemon: Address: 0x6 Access: read. Address not mapped to object.
2022.09.08 09:20:56.777500 [ 2857169 ] {} <Fatal> BaseDaemon: Stack trace: 0x1668ecb5 0x1739af43 0x12df9570 0x171903a7 0x171af8da 0x171a47fe 0x171a60c4 0xb94d077 0xb95049d 0x7fabdf964609 0x7fabdf889133
2022.09.08 09:20:56.777560 [ 2857169 ] {} <Fatal> BaseDaemon: 2. DB::ColumnString::compareAt(unsigned long, unsigned long, DB::IColumn const&, int) const @ 0x1668ecb5 in /usr/bin/clickhouse
2022.09.08 09:20:56.777583 [ 2857169 ] {} <Fatal> BaseDaemon: 3. DB::PartialSortingTransform::transform(DB::Chunk&) @ 0x1739af43 in /usr/bin/clickhouse
2022.09.08 09:20:56.777604 [ 2857169 ] {} <Fatal> BaseDaemon: 4. DB::ISimpleTransform::transform(DB::Chunk&, DB::Chunk&) @ 0x12df9570 in /usr/bin/clickhouse
2022.09.08 09:20:56.777627 [ 2857169 ] {} <Fatal> BaseDaemon: 5. DB::ISimpleTransform::work() @ 0x171903a7 in /usr/bin/clickhouse
2022.09.08 09:20:56.777644 [ 2857169 ] {} <Fatal> BaseDaemon: 6. DB::ExecutionThreadContext::executeTask() @ 0x171af8da in /usr/bin/clickhouse
2022.09.08 09:20:56.777664 [ 2857169 ] {} <Fatal> BaseDaemon: 7. DB::PipelineExecutor::executeStepImpl(unsigned long, std::__1::atomic<bool>*) @ 0x171a47fe in /usr/bin/clickhouse
2022.09.08 09:20:56.777691 [ 2857169 ] {} <Fatal> BaseDaemon: 8. ? @ 0x171a60c4 in /usr/bin/clickhouse
2022.09.08 09:20:56.777714 [ 2857169 ] {} <Fatal> BaseDaemon: 9. ThreadPoolImpl<std::__1::thread>::worker(std::__1::__list_iterator<std::__1::thread, void*>) @ 0xb94d077 in /usr/bin/clickhouse
2022.09.08 09:20:56.777774 [ 2857169 ] {} <Fatal> BaseDaemon: 10. ? @ 0xb95049d in /usr/bin/clickhouse
2022.09.08 09:20:56.777792 [ 2857169 ] {} <Fatal> BaseDaemon: 11. ? @ 0x7fabdf964609 in ?
2022.09.08 09:20:56.777805 [ 2857169 ] {} <Fatal> BaseDaemon: 12. clone @ 0x7fabdf889133 in ?
2022.09.08 09:20:56.971010 [ 2857169 ] {} <Fatal> BaseDaemon: Integrity check of the executable successfully passed (checksum: 894C4AAB85FCB9AAC26136BC446CC5AF)
```

I froze the partition and attached it to local clickhouse server running newest 22.8 version and the random timestamp problem was still there. I couldn't get it to produce a segfault but the local instance has no other query running on it so that's not really comparable.

Has someone seen anything like this before?

I would be happy to share the partition since that's probably where the problem lies but the data stored on it is private. Is there some method of randomizing/encrypting the column_* columns without affecting the primary key?
if (description.size() == 1)
    {
        
        raw_block_columns[0]->compareColumn(*threshold_columns[0], 0, nullptr, compare_results,
                              description[0].direction, description[0].nulls_direction);
    }
    else
    {
        rows_to_compare.resize(num_rows);
        for (size_t i = 0; i < num_rows; ++i)
            rows_to_compare[i] = i;
        size_t size = description.size();
        for (size_t i = 0; i < size; ++i)
        {
            raw_block_columns[i]->compareColumn(*threshold_columns[i], 0, &rows_to_compare, compare_results,
                                  description[i].direction, description[i].nulls_direction);
            if (rows_to_compare.empty())
                break;
        }
    }
    size_t result_size_hint = 0;
    for (size_t i = 0; i < num_rows; ++i)
    {
        
        filter[i] = compare_results[i] < 0;
        result_size_hint += filter[i];
    }
    return result_size_hint;
}
bool compareWithThreshold(const ColumnRawPtrs & raw_block_columns, size_t min_block_index, const Columns & threshold_columns, const SortDescription & sort_description)