yjhjstz commented on issue #1900:
URL: https://github.com/apache/cloudberry/issues/1900#issuecomment-5331889520
Thanks for the report — reproduced and root-caused. This is fixed by #1902.
Reproduction. We reproduced the segfault on the exact release build you're
running (2.1.0-incubating, bdf90c5518f). The query text in the report is
truncated at , cte2 as, but a faithful reconstruction of the same shape
(multi-CTE CTAS where cte1 is SELECT *, <computed columns> FROM cte and the
CTEs are referenced more than once downstream) crashes all segment processes
deterministically with signal 11, matching your log.
Root cause. It's a GPORCA bug in CTE column pruning with multiple consumers.
When a CTE is referenced by several consumers, the producer's shared-scan
output is pruned to the union of the columns the consumers actually need
(CTranslatorDXLToExpr::PruneCTEs). However, each consumer independently decided
its own output columns in CPhysicalCTEConsumer, and a SELECT *-style consumer
kept an identity column map over the unpruned layout. That consumer then
deforms the shared tuple at stale positions.
The core dump shows it precisely: the crash is in slot_deform_heap_tuple
reading the shared-scan tuple — the consumer's slot descriptor has 9 attributes
while the physical tuple written by the producer has 8. A variable-length
column (numeric/varchar) gets parsed at the wrong offset, producing a garbage
length and an out-of-bounds read → SIGSEGV. Note that depending on data, the
same bug can also manifest as silently wrong results (columns coming back NULL)
or ERROR: invalid attnum N for relation "shareX_refY" during EXPLAIN, instead
of a crash.
Workaround until you can upgrade: run the statement with the Postgres
planner:
SET optimizer = off;
Fix. Fixed on main by 3d1c8cdf79af159e82cf22c0f08b1f343996efe8 ("ORCA: fix
CTE column-pruning misalignment across consumers"); the backport to
REL_2_STABLE is #1902, so it will be included in the next 2.x release. We
verified your query shape on a patched build: no crash, plans still use shared
scans, and results match the Postgres planner row-for-row.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
