Skip to content

Fix LOGICAL_ERROR when ROW POLICY is used with ALIAS column containing dictGet#99065

Merged
antaljanosbenjamin merged 5 commits intoClickHouse:masterfrom
fastio:bugfix-94659
Mar 19, 2026
Merged

Fix LOGICAL_ERROR when ROW POLICY is used with ALIAS column containing dictGet#99065
antaljanosbenjamin merged 5 commits intoClickHouse:masterfrom
fastio:bugfix-94659

Conversation

@fastio
Copy link
Contributor

@fastio fastio commented Mar 9, 2026

Changelog category (leave one):

  • Bug Fix (user-visible misbehavior in an official stable release)

Changelog entry (a user-readable short description of the changes that goes into CHANGELOG.md):

Fix LOGICAL_ERROR when querying a table that has both a ROW POLICY and an ALIAS column using dictGet. The issue was caused by premature access to the table expression during ALIAS column resolution in the
new analyzer.

Fixes #94659

Documentation entry for user-facing changes

  • Documentation is written (mandatory for new features)

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 dictGet was queried while a ROW POLICY was active on that
table.

#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_ERROR when a table has both a ROW POLICY and an ALIAS column using dictGet by marking the current table_expression as in resolve while running initializeTableExpressionData, 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.

@bharatnc bharatnc added the can be tested Allows running workflows for external contributors label Mar 9, 2026
@clickhouse-gh
Copy link
Contributor

clickhouse-gh bot commented Mar 9, 2026

Workflow [PR], commit [8055fda]

Summary:

@clickhouse-gh clickhouse-gh bot added the pr-bugfix Pull request with bugfix, not backported by default label Mar 9, 2026
@antaljanosbenjamin antaljanosbenjamin self-assigned this Mar 9, 2026
Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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() in QueryAnalyzer::resolve() for expression nodes.
  • Add a stateless regression test reproducing ROW POLICY + dictGet ALIAS behavior (including an enable_analyzer=0 control 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.

Comment on lines +1 to +8
-- 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;
Copy link

Copilot AI Mar 9, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).

Copilot uses AI. Check for mistakes.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a useful tip for sure.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I have fixed it.

@@ -0,0 +1,53 @@
-- Tags: no-parallel
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

-- 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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess no-parallel is because of the row policy, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I checked the ROW POLICY test cases; there’s no need to add the no-parallel tag. I remove it now.

@fastio
Copy link
Contributor Author

fastio commented Mar 15, 2026

Hi @antaljanosbenjamin, Could you please review this PR when you have a chance?

@@ -0,0 +1,53 @@
-- Tags: no-parallel
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess no-parallel is because of the row policy, right?

@clickhouse-gh
Copy link
Contributor

clickhouse-gh bot commented Mar 18, 2026

LLVM Coverage Report

Metric Baseline Current Δ
Lines 83.80% 83.70% -0.10%
Functions 23.90% 23.90% +0.00%
Branches 76.40% 76.30% -0.10%

PR changed lines: PR changed-lines coverage: 100.00% (18/18, 0 noise lines excluded)
Diff coverage report
Uncovered code

@fastio
Copy link
Contributor Author

fastio commented Mar 19, 2026

@antaljanosbenjamin Hi, -- Tags : no-parallel is not required. I've removed it.

@antaljanosbenjamin antaljanosbenjamin added this pull request to the merge queue Mar 19, 2026
@antaljanosbenjamin
Copy link
Member

Thanks for the great work and sorry for dragging the review, I have quite a packed few days (weeks?) behind me.

Merged via the queue into ClickHouse:master with commit a747d8a Mar 19, 2026
163 checks passed
@robot-ch-test-poll1 robot-ch-test-poll1 added the pr-synced-to-cloud The PR is synced to the cloud repo label Mar 19, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

can be tested Allows running workflows for external contributors pr-bugfix Pull request with bugfix, not backported by default pr-synced-to-cloud The PR is synced to the cloud repo

Projects

None yet

Development

Successfully merging this pull request may close these issues.

SELECT fails with new analyzer on table with ROW POLICY

5 participants