[Bug] INCLUDE (non-key) index column referenced by a predicate is treated as valid
メンテナーはふだん 3 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 初心者へのやさしさ
- 32/100
調査の方向性
The bug is in GPORCA's construction of index conditions, and the issue suspects CXformUtils::PdrgpcrIndexColumns, which merges key and INCLUDE columns into one array. Reproduce the two SELECT statements with optimizer on and compare against optimizer off, then check which Index Cond the plan builds and where nodeIndexscan.c rejects it. Done means both queries return rows under optimizer=on without either sanity-check error. The issue reports an unmerged local fix but does not name a target design, so confirm the expected behaviour with maintainers first.
索引モデルが issue の本文から書いたものです。
説明
Apache Cloudberry version
No response
What happened
A GPORCA bug: an INCLUDE (non-key) index column referenced by a predicate is treated as a valid
index key column when building an Index Cond (likely via CXformUtils::PdrgpcrIndexColumns, which
concatenates key and included columns into one array with no marker distinguishing the two). The
resulting plan carries a scan key against an attribute beyond indnkeyatts, which the executor
rejects. Which sanity check fires depends on the predicate, so one bug produces two error
messages -- both are suppressed below:
CREATE TABLE t(a int, b ); CREATE INDEX i ON t USING btree (a) INCLUDE (b);
SET optimizer = on;
SELECT a FROM t WHERE b; -- b boolean: "bogus index qualification (nodeIndexscan.c)"
SELECT a FROM t WHERE b IS NULL; -- b int: "btree index keys must be ordered by attribute"
Verified scope: optimizer=on only (the Postgres planner never builds such an Index Cond, and
every case above returns the correct rows under optimizer=off); not specific to a distribution
policy (DISTRIBUTED BY and DISTRIBUTED REPLICATED both reproduce); needs no data, an empty table
is enough; and the INCLUDE list does not have to overlap the key columns -- a plain
"INCLUDE (b)" is sufficient. A fix exists locally but has not been merged into the Cloudberry
main branch this environment is built from.
What you think should happen instead
No response
How to reproduce
CREATE TABLE t(a int, b int); CREATE INDEX i ON t USING btree (a) INCLUDE (b);
SET optimizer = on;
SELECT a FROM t WHERE b IS NULL; -- b int: "btree index keys must be ordered by attribute"
Operating System
any
Anything else
No response
Are you willing to submit PR?
- Yes, I am willing to submit a PR!
Code of Conduct
- I agree to follow this project's Code of Conduct.
- 主要言語
- C
- スター
- 1.4k
- フォーク
- 262
- 平均マージ
- 4日 20時間
- マージ済み PR（30日）
- 57
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートあり
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
apache/cloudberry のほかの issue
-
[Bug] Expand fails to recognize user-defined tablespaces対応中かも @nix-oss が 61 日前に担当しました。 オープンtype: Bug
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
apache/cloudberry#1885 · リアクション 2 件 ·
メンテナーはふだん 3 日以内に返信
-
gpexpand first stage fails: 'SyncPackages' object has no attribute 'ret' (extension sync never runs; regression)対応中かも @talmacschen-arch が 122 日前に担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 86/100
apache/cloudberry#1825 ·
メンテナーはふだん 3 日以内に返信
-
Lance support: contrib/lance_fdw and the MCP server's Lance tools対応中かも @MisterRaindrop が 2 日前に担当しました。 オープン
apache/cloudberry#2139 · 担当者 1 名 ·
メンテナーはふだん 3 日以内に返信
-
type: Bug
難易度 3/5 半日 初心者へのやさしさ 58/100
apache/cloudberry#2137 ·
メンテナーはふだん 3 日以内に返信
-
type: Proposal
難易度 4/5 3〜5日 初心者へのやさしさ 22/100
apache/cloudberry#2136 · コメント 1 件 ·
メンテナーはふだん 3 日以内に返信
apache/cloudberry の issue をすべて見る
似ている issue
-
難易度 1/5 1時間未満 初心者へのやさしさ 91/100
FujiNetWIFI/fujinet-firmware#2045 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100
OpenPrinting/cups#1772 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
snowballstem/snowball#311 ·
-
tech-debt
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
メンテナーはふだん 1 日以内に返信