[Bug] ORCA: QD segfault in CExtendedStatsProcessor when extended statistics (dependencies) do not cover all filtered columns #1949

Apache Cloudberry version

main branch (recent build)

What happened

With ORCA enabled, the backend crashes when a query filters on a set of columns that is only partially covered by an extended statistics object (CREATE STATISTICS ... (dependencies)). In the reproducer below the statistics object covers c0, c1 and the outer WHERE also references c2, which is not covered.

The crash is a null-pointer dereference in the QD backend inside ORCA's statistics derivation:

CExtendedStatsProcessor::ApplyCorrelatedStatsToScaleFactorFilterCalculation
  (libnaucrates/src/statistics/CExtendedStatsProcessor.cpp, ~line 366)
  <- CFilterStatsProcessor::MakeHistHashMapConjFilter
  <- CLogicalSelect::PstatsDerive

colid_to_attno_mapping->Find(&colid) returns nullptr for the column that is not part of the statistics object, and the result is dereferenced without a check.

With optimizer = off the query runs fine and returns 0 rows.

Found by SQLancer.

What you think should happen instead

The query should run and return 0 rows (no row has c1 = ''). Cardinality estimation must not assume every filtered column is present in the extended statistics object.

How to reproduce

CREATE TABLE t3 (c0 boolean, c1 text, c2 int) DISTRIBUTED BY (c0);
INSERT INTO t3 SELECT (g%2=0), 'x'||g, g FROM generate_series(1,100) g;
CREATE STATISTICS s0 (dependencies) ON c0, c1 FROM t3;   -- covers c0, c1 only
ANALYZE t3;

SET optimizer = on;
SELECT * FROM (SELECT ALL t3.c0 AS t3c0, t3.c1 AS t3c1, t3.c2 AS t3c2
               FROM t3
               WHERE (t3.c0) IS TRUE
               GROUP BY t3.c0, t3.c1, t3.c2
               ORDER BY t3.c1) AS result
WHERE result.t3c0 = TRUE AND result.t3c1 = '' AND result.t3c2 > 0;   -- c2 not covered by s0
-- QD backend SIGSEGV

Operating System

Linux

Anything else

Found while running SQLancer against Cloudberry main (3-segment demo cluster, --enable-cassert). See the proposal to run SQLancer continuously: #1952

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