Fix LOGICAL_ERROR when ROW POLICY is used with ALIAS column containing dictGet#99065
Fix LOGICAL_ERROR when ROW POLICY is used with ALIAS column containing dictGet#99065antaljanosbenjamin merged 5 commits intoClickHouse:masterfrom
Conversation
There was a problem hiding this comment.
Pull request overview
Fixes a new-analyzer LOGICAL_ERROR triggered when querying a table that has an active ROW POLICY and an ALIAS column using dictGet, by preventing premature access to partially-initialized table-expression data during single-expression resolution.
Changes:
- Add a “table expression is in resolve” guard around
initializeTableExpressionData()inQueryAnalyzer::resolve()for expression nodes. - Add a stateless regression test reproducing ROW POLICY +
dictGetALIAS behavior (including anenable_analyzer=0control query). - Add expected output reference for the new test.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
src/Analyzer/Resolve/QueryAnalyzer.cpp |
Adds a guard in QueryAnalyzer::resolve() to avoid premature table-expression access during ALIAS resolution. |
tests/queries/0_stateless/04033_issue_94659.sql |
New regression test reproducing the crash scenario and validating both analyzers. |
tests/queries/0_stateless/04033_issue_94659.reference |
Expected output for the new stateless test. |
You can also share your feedback on Copilot code review. Take the survey.
| -- Tags: no-parallel | ||
| -- Issue: https://github.com/ClickHouse/ClickHouse/issues/94659 | ||
| -- ROW POLICY + ALIAS column with dictGet should not cause LOGICAL_ERROR | ||
|
|
||
| DROP ROW POLICY IF EXISTS pol_94659 ON t1_94659; | ||
| DROP TABLE IF EXISTS t1_94659; | ||
| DROP DICTIONARY IF EXISTS d1_94659; | ||
| DROP TABLE IF EXISTS t2_94659; |
There was a problem hiding this comment.
This regression test relies on whatever the default enable_analyzer value is for the test runner. To ensure it actually exercises the new analyzer path that used to crash, please add an explicit SET enable_analyzer = 1; near the top (and keep the enable_analyzer = 0 query as-is for the old-analyzer check).
There was a problem hiding this comment.
This is a useful tip for sure.
There was a problem hiding this comment.
Yes, I have fixed it.
| @@ -0,0 +1,53 @@ | |||
| -- Tags: no-parallel | |||
There was a problem hiding this comment.
-- Tags: no-parallel looks unnecessary here because all object names are uniquely suffixed (*_94659), so this test should be isolated and parallel-safe. Keeping no-parallel reduces CI throughput; please remove the tag unless there is a reproducible parallel conflict that requires it.
There was a problem hiding this comment.
I guess no-parallel is because of the row policy, right?
There was a problem hiding this comment.
I checked the ROW POLICY test cases; there’s no need to add the no-parallel tag. I remove it now.
|
Hi @antaljanosbenjamin, Could you please review this PR when you have a chance? |
| @@ -0,0 +1,53 @@ | |||
| -- Tags: no-parallel | |||
There was a problem hiding this comment.
I guess no-parallel is because of the row policy, right?
LLVM Coverage Report
PR changed lines: PR changed-lines coverage: 100.00% (18/18, 0 noise lines excluded) |
|
@antaljanosbenjamin Hi, |
|
Thanks for the great work and sorry for dragging the review, I have quite a packed few days (weeks?) behind me. |
Changelog category (leave one):
Changelog entry (a user-readable short description of the changes that goes into CHANGELOG.md):
Fix
LOGICAL_ERRORwhen querying a table that has both a ROW POLICY and an ALIAS column usingdictGet. The issue was caused by premature access to the table expression during ALIAS column resolution in thenew analyzer.
Fixes #94659
Documentation entry for user-facing changes
No documentation changes required. This is a bug fix for an internal error (LOGICAL_ERROR) that occurred when a table with an ALIAS column referencing
dictGetwas queried while a ROW POLICY was active on thattable.
#94659
Note
Medium Risk
Touches core query analyzer resolution flow by adding resolve-in-progress guarding around
initializeTableExpressionData, which could affect identifier resolution for some queries. Change is small but in a central code path and validated by a targeted regression test.Overview
Fixes a new-analyzer
LOGICAL_ERRORwhen a table has both a ROW POLICY and an ALIAS column usingdictGetby marking the currenttable_expressionas in resolve while runninginitializeTableExpressionData, preventing premature access during ALIAS column resolution.Adds a stateless regression test (
04033_issue_94659) covering selects with/without the ALIAS column, with an active row policy, and ensuring the old analyzer path still works.Written by Cursor Bugbot for commit 927f83a. This will update automatically on new commits. Configure here.