All committers have signed the CLA.

Workflow [PR], commit [8adb439]

Summary: ❌

AI Review

Summary

This PR adds parser support for SQL truth-value predicates (IS TRUE, IS FALSE, IS UNKNOWN, and IS NOT variants), rewrites them to existing comparison/null-check functions, documents the new operators, and adds a focused stateless test. I reviewed the current diff and prior discussion threads against the latest code, and I do not see unresolved contract violations in correctness, safety, compatibility, or rollout behavior.

Final Verdict

Status: ✅ Approve

@alexey-milovidov I checked the failing tests, and they do not seem to be caused by the new changes in this PR. Please let me know whether I should investigate them or treat them as unrelated CI failures.

@ibrahimkarimeddin, check this https://s3.amazonaws.com/clickhouse-test-reports/json.html?PR=99997&sha=ee482d21a5ba665f0895314230eee1ca8432f858&name_0=PR&name_1=Finish%20Workflow

@alexey-milovidov just a kind reminder on this PR. If any further updates are needed from my side, I’m ready to make them.

@alexey-milovidov sorry for the ping — quick question as this is my first time. Do I need to do anything after approval for the PR to be merged, or does it just take some time?

We will take it from here.

Fix for the integration test: #101897

Now we have to fix the hung queries in the Stress test...

The Hung check failure is fixed by #102008 and #102010, let's update the branch

I fixed the hung check, will update the branch.

Hi @alexey-milovidov , gentle follow-up on this PR. Thanks again for the review and help here. Please let me know if anything else is needed from my side.

I will take it from here. The CI is not green, we have to fix the CI first.

Merged latest master into the branch and pushed (8adb439e4f5d). CI should re-run.

CI failures analysis (from the previous run)

The two failing checks are unrelated to this PR (which only touches the SQL parser):

1. Stateless tests (amd_binary, flaky check) — timeout in 03207_json_read_subcolumns_2_memory. This is a JSON subcolumns test, no relation to truth-value predicates.
2. Stress test (arm_msan) — MemorySanitizer: use-of-uninitialized-value inside DB::MergeTreeReadersChain::executeActionsBeforePrewhere, with the uninitialized memory created by an allocation of patch_max_version in src/Storages/MergeTree/MergeTreeReadersChain.cpp:210. Entirely in MergeTree read code.

@groeneai, investigate both unrelated failures:

• https://s3.amazonaws.com/clickhouse-test-reports/json.html?PR=99997&sha=1b7c5887c2f7a873987b69f56d3848abf23cbf38&name_0=PR&name_1=Stateless%20tests%20%28amd_binary%2C%20flaky%20check%29
• https://s3.amazonaws.com/clickhouse-test-reports/json.html?PR=99997&sha=1b7c5887c2f7a873987b69f56d3848abf23cbf38&name_0=PR&name_1=Stress%20test%20%28arm_msan%29

@alexey-milovidov — investigated both failures. Both are pre-existing trunk issues, unrelated to this PR's parser-only diff.

1. Stress test (arm_msan) — MemorySanitizer: use-of-uninitialized-value (STID: 1478-2063)

This is the same chronic MSan trunk bug tracked by #102241 (which was closed as completed on 2026-04-10, but the bug is still active — see below).

The stack shows the uninitialized value is reported through TextLog::appendToBlock → OwnAsyncSplitChannel::runTextLog, and MSan attributes the allocation to patch_max_version in MergeTreeReadersChain::executeActionsBeforePrewhere at src/Storages/MergeTree/MergeTreeReadersChain.cpp:210. The actual variable is the std::optional<UInt64> returned by getMaxPatchVersionForStep (which just forwards prewhere_info->mutation_version). The poison is then propagated through patch-application machinery and eventually surfaces in a Poco::Message constructor when text logs are flushed asynchronously.

Cross-PR distribution (last 30 days, stress-test rows whose test_context_raw mentions patch_max_version or MergeTreeReadersChain): 24+ distinct PRs affected, all sanitizer/architecture variants:

pull_request_number  check_name                              cnt  last_day
100185               Stress test (amd_asan_ubsan)             1   2026-05-05
100185               Stress test (amd_msan)                   1   2026-05-05
100185               Stress test (arm_msan)                   1   2026-05-14
100185               Stress test (arm_tsan)                   1   2026-05-05
100185               Stress test (amd_debug)                  1   2026-05-14
104494               Stress test (arm_asan_ubsan, s3)         1   2026-05-15
104903               Stress test (amd_debug)                  1   2026-05-14
104120               Stress test (amd_msan)                   1   2026-05-06
... and ~16 more PRs across amd/arm × debug/asan/tsan/msan/ubsan

Master hits (pull_request_number = 0) in the last 60 days:

day          failures  checks
2026-05-14   1         Stress test (experimental, serverfuzz, azure, amd_tsan)
2026-05-11   1         Stress test (experimental, serverfuzz, arm_tsan)
2026-05-07   1         Stress test (experimental, serverfuzz, amd_tsan)
2026-04-25   1         Stress test (amd_debug)
2026-04-21   1         Stress test (experimental, serverfuzz, amd_debug)
2026-04-10   4         Stress test (arm_msan)

8 master hits in 60 days, latest 2026-05-14. #102241 should likely be reopened — the bug is still recurring on master (including the serverfuzz nightlies) more than a month after the issue was closed.

PR #102305 (Unpoison fiber stack on AArch64) and PR #102290 (Rollback jemalloc upgrade) were both opened as candidate fixes but closed without merging, so the root cause remains unaddressed.

2. Stateless tests (amd_binary, flaky check) — 03207_json_read_subcolumns_2_memory timeout

Only relevant to the flaky-check stage (which re-runs new/changed tests 50× under heavy randomization within a 600s budget). The test itself is intrinsically heavy: 800K rows of JSON data with max_dynamic_paths=2 and dozens of SELECT json.… paths-with-types queries.

Cross-PR distribution (last 60 days):

pull_request_number  cnt  first_day    last_day     checks
99513                5    2026-03-25   2026-03-26   amd_llvm_coverage variants
102269               2    2026-04-10   2026-04-13   amd_binary, flaky check
99997                2    2026-04-10   2026-04-10   amd_binary, flaky check
101645               2    2026-04-10   2026-04-10   amd_binary, flaky check
101918               1    2026-04-10   2026-04-10   amd_binary, flaky check
100535               1    2026-04-10   2026-04-10   amd_binary, flaky check
96130                1    2026-03-21   2026-03-21   arm_binary, parallel

Master hits in 60 days: 0.

5 of the 6 amd_binary, flaky check hits cluster on a single day (2026-04-10) across completely unrelated PRs (#102269, #99997, #101645, #101918, #100535) — same day the run we're looking at was performed. That looks like a CI infrastructure or shared-resource event on that runner, not a property of this PR.

Note: I previously merged #101765 for the sibling test 03469_json_read_subcolumns_combined_2_compact_merge_tree, which had a similar randomized-settings-induced timeout. The same approach (capping index_granularity / index_granularity_bytes and pinning max_threads) likely applies to 03207_json_read_subcolumns_2_memory if it surfaces again. I'll open a follow-up for that.

Conclusion

Both failures are pre-existing trunk issues that pre-date this PR. The new CI run on 8adb439e4f5d should be fine for the flaky-check timeout (the cluster of 2026-04-10 hits looks transient) and may also miss the MSan report (it's stochastic at ~one hit per few days per build variant), but the MSan signature itself is master-bug territory and not caused by the parser changes here. I'll file a follow-up to revisit #102241 / extend the timeout fix to 03207_json_read_subcolumns_2_memory.

Correction on the MSan analysis above — I was over-inclusive with my pattern matching.

The test_context_raw LIKE '%patch_max_version%' OR LIKE '%MergeTreeReadersChain%' query I ran above also matches stress runs whose attached server log contains other unrelated failures (Logical errors, Hung check, etc.) — the MergeTreeReadersChain::executeActionsBeforePrewhere frame appears in many normal query stack traces, so the broader query is noisy.

Filtering to the actual STID test_name:

SELECT toStartOfDay(check_start_time) AS day, count() AS failures, any(check_name) AS check
FROM default.checks
WHERE test_name = 'MemorySanitizer: use-of-uninitialized-value (STID: 1478-2063)'
  AND test_status IN ('FAIL', 'ERROR')
  AND pull_request_number = 0
  AND check_start_time > now() - INTERVAL 60 DAY
GROUP BY day ORDER BY day DESC

day          failures  check
2026-04-10   3         Stress test (arm_msan)
2026-04-09   12        Stress test (arm_msan)
2026-04-08   1         Stress test (arm_msan)
2026-04-03   1         Stress test (arm_msan)

Zero master hits since 2026-04-10, so STID 1478-2063 itself does appear to be resolved (likely consistent with #102241 being closed on that same day).

The CI failure linked from this PR is on SHA 1b7c5887c2f7… — checking the failure log timestamps, that run is from 2026-04-10 08:21, i.e. before the fix that closed #102241 landed. So this is a stale CI run, not a fresh MSan recurrence. The new CI on 8adb439e4f5d should not reproduce it.

Same story for the 03207_json_read_subcolumns_2_memory flaky-check timeout — also from the 2026-04-10 run cluster, also stale.

TL;DR: Both failures are stale CI from 2026-04-10. The new run on 8adb439e4f5d should be green; no further investigation needed on my side. Apologies for the noise on #102241 — that one looks legitimately fixed.

LLVM Coverage Report

Changed lines: 94.34% (50/53) | lost baseline coverage: 1 line(s) · Uncovered code

Full report · Diff report