This is an automated comment for commit 13f4d0d with description of existing statuses. It's updated for the latest CI running

❌ Click here to open a full report in a separate page

I think it should also throw an exception when we are trying to shift for more than type width.
While this behaviour seems different from the MySQL for example, I'd better have the same behaviour as C++ compiler https://godbolt.org/z/asjGWMnbj

I think it should also throw an exception when we are trying to shift for more than type width. While this behaviour seems different from the MySQL for example, I'd better have the same behaviour as C++ compiler https://godbolt.org/z/asjGWMnbj

Done! Even though at first I was a bit reluctant of this change because for bitShift I didn't see it causing any harm. However, it's true that most likely if you ever try to shift more positions than the value bit width, you're making a mistake.

• ClickHouse Upgrade Check

New settings are not reflected in settings changes history (see new_settings.txt)

Unrelated

• ClickHouse Stress Test (tsan)

Unrelated possible deadlock. The test that hung has 0 references to any bitShift function. I've created #66043 and #66044 to address them

• ClickHouse Stateless Tests

Unrelated test failure, 02247_read_bools_as_numbers_json failed due to an assertion in jemalloc. It's failed quite a few times lately, so I've created an issue for it: #66029

• ClickHouse performance comparison

All of the tests reported have no relation with these changes. None use bitShift

• ClickHouse Integration Tests (tsan)

Unrelated test error: test_materialized_mysql_database/test.py::test_materialized_database_mysql_date_type_to_date32
I've created #66047

• ClickHouse Bugfix Validation

Seems it failed to install the deb package:

dpkg: error: cannot access archive 'package_folder/clickhouse-common-static-dbg_*.deb': No such file or directory

Unrelated to the PR. There's already an issue for it: #65946

• Cloud fork sync - Stateless tests

Unrelated test 03037_dynamic_merges_1_vertical failed. I've created #66048

I'm sorry, my request to enumerate all the crashed tests was formulated a bit harsh. Next time just write a comment, that you scanned all the crashed jobs and all of them seems unrelated to your PR or are already flaky

It would be great if you create issues about some unreported crashes from your CI run. Usually these crashes are already reported, but sometimes some new bugs can be found

I'm sorry, my request to enumerate all the crashed tests was formulated a bit harsh. Next time just write a comment, that you scanned all the crashed jobs and all of them seems unrelated to your PR or are already flaky

Ok, no worries. Understood.

It would be great if you create issues about some unreported crashes from your CI run. Usually these crashes are already reported, but sometimes some new bugs can be found

I had already created an issue that it was clearly a flaky test. I've reviewed again the rest and created issues for those missing. I edited my comment with the new issues created.

Let me know if there's anything else missing in the PR that I need to address.

Let me know if there's anything else missing in the PR that I need to address.

Could you take a look at comment about the right part of the expression const UInt256 bit_limit = word_size * n?

Could you take a look at comment about the right part of the expression const UInt256 bit_limit = word_size * n?

@divanik I don't see any comment anywhere 😢 . Are you sure you submitted the review/comment? If so, please share a link to the comment, because there's nothing I can see as of now.

Two more issues created after checking that the some CI check failed: #66116 and #66117

However, it's true that most likely if you ever try to shift more positions than the value bit width, you're making a mistake.

It's "wrong"

CH always try to use least type possible, so in case of literals, you will get different behavior based on typed value itself.
And this behavior is somewhat special, other DBMS usually use much wider type like 64 bit by default

SELECT bitShiftLeft(256, 10);

0

SELECT bitShiftLeft(1, 10)

Received exception from server (version 24.11.1):
Code: 69. DB::Exception: Received from localhost:9000. DB::Exception: The number of shift positions needs to be a non-negative value and less or equal to the bit width of the value to shift: In scope SELECT bitShiftLeft(1, 10). (ARGUMENT_OUT_OF_BOUND)
(query: SELECT bitShiftLeft(1, 10))

https://fiddle.clickhouse.com/9c0486da-172c-4b1b-b145-248eb5a3c51e

And this behavior is somewhat special, other DBMS usually use much wider type like 64 bit by default

As a workaround in ClickHouse you can always cast to whatever you want to bypass this exception:

SELECT bitShiftLeft(256, 10);
SELECT bitShiftLeft(1::Int64, 10)

https://fiddle.clickhouse.com/856ae8e4-746d-4966-a2c1-6922512d7d09

As a workaround in ClickHouse you can always cast to whatever you want to bypass this exception:

So, basically, it does mean that you "always" need to do additional cast within bitShift operator, because there are functions exist in CH, which return smaller types than arguments. (modulo as example).

If "accurate" behavior is needed, it make more sense to introduce additional set of functions, like cast vs accurateCast