Master Node PANIC Triggered by GPORCA When Using Unsupported Ordered-Set Aggregates
Article ID: 433061
Updated On:
Products
Issue/Introduction
Issue Description
When executing specific queries containing unsupported ordered-set aggregate functions (such as mode()), the Greenplum Master node may experience a PANIC and crash.
This issue occurs specifically when the GPORCA optimizer is enabled and encounters an unsupported aggregate function combined with the within group (order by ...) clause.
Symptoms:
-
Master node crashes/PANICs during query execution.
-
The stack trace in the log indicates that the failure occurs within the
UlOrderedAggs(ordered aggregates) code path in GPORCA.
Below is an example of the stack trace generated during this issue:
2026-03-10 14:20:07.855655 CST,,,p2018723,th0,,,2026-03-10 14:19:56 CST,0,con16,cmd5,seg-1,,,,,"PANIC","XX000","Unexpected internal error: Master process received signal SIGSEGV",,,,,,,0,,,,"1 0x7fbc6beb5d10 libpthread.so.0 <symbol not found> + 0x6beb5d10
2 0xfe85a7 postgres _ZN5gpopt18CScalarProjectList13UlOrderedAggsERNS_17CExpressionHandleE + 0x77
3 0xf2e20a postgres _ZN5gpopt15CDrvdPropScalar22DeriveTotalOrderedAggsERNS_17CExpressionHandleE + 0x4a
4 0xf74522 postgres _ZN5gpopt11CExpression22DeriveTotalOrderedAggsEv + 0x32
5 0xfedf35 postgres _ZN5gpopt23COrderedAggPreprocessor15PexprPreprocessEPN4gpos11CMemoryPoolEPNS_11CExpressionE + 0x295
6 0xf886f1 postgres _ZN5gpopt23CExpressionPreprocessor15PexprPreprocessEPN4gpos11CMemoryPoolEPNS_11CExpressionEPNS_10CColRefSetE + 0x4a1
7 0xf3bd99 postgres _ZN5gpopt13CQueryContextC2EPN4gpos11CMemoryPoolEPNS_11CExpressionEPNS_13CReqdPropPlanEPNS1_16CDynamicPtrArrayINS_7CColRefEXadL_ZNS1_11CleanupNULLIS9_EEvPT_EEEEPNS8_IN4gpmd7CMDNameEXadL_ZNS1_13CleanupDeleteISG_EEvSC_EEEEb + 0xd9
8 0xf3c352 postgres _ZN5gpopt13CQueryContext11PqcGenerateEPN4gpos11CMemoryPoolEPNS_11CExpressionEPNS1_16CDynamicPtrArrayIjXadL_ZNS1_13CleanupDeleteIjEEvPT_EEEEPNS6_IN4gpmd7CMDNameEXadL_ZNS7_ISD_EEvS9_EEEEb + 0x4a2
9 0xff1190 postgres _ZN5gpopt10COptimizer13PdxlnOptimizeEPN4gpos11CMemoryPoolEPNS_11CMDAccessorEPKN5gpdxl8CDXLNodeEPKNS1_16CDynamicPtrArrayIS7_XadL_ZNS1_14CleanupReleaseIS7_EEvPT_EEEESG_PNS_19IConstExprEvaluatorEjjjPNSA_INS_12CSearchStageEXadL_ZNS1_13CleanupDeleteISJ_EEvSD_EEEEPNS_16COptimizerConfigEPKc + 0x1c0
10 0x10f0717 postgres _ZN9COptTasks12OptimizeTaskEPv + 0xc17
11 0xddc2ce postgres _ZN4gpos5CTask7ExecuteEv + 0x2e
12 0xddd0b8 postgres _ZN4gpos7CWorker7ExecuteEPNS_5CTaskE + 0x18
13 0xddbaa9 postgres _ZNK4gpos14CAutoTaskProxy7ExecuteEPNS_5CTaskE + 0x49
14 0xdddad4 postgres gpos_exec + 0x224
15 0x10ece4f postgres _ZN9COptTasks7ExecuteEPFPvS0_ES0_ + 0x5f
16 0x10edb66 postgres _ZN9COptTasks18GPOPTOptimizedPlanEP5QueryP11SOptContext + 0x16
Steps to Reproduce
The issue can be consistently reproduced using a simplified query where the mode() function is combined with a within group clause.
Example Query:
explain SELECT
mode() within group (order by <column>) AS xx
FROM <table> ;Cause
Root Cause
The GPORCA optimizer fails and crashes when processing queries that contain unsupported ordered-set aggregates like mode(). GPORCA is designed to split queries using only supported ordered-set aggregates (which are limited to percentile_disc, percentile_cont, and median), but earlier versions lacked the proper checks to safely handle unsupported functions in this path.
Resolution
Workaround
If an immediate upgrade is not possible, you can bypass this issue by disabling the GPORCA optimizer for the session before executing the problematic query. This forces the query to use the Postgres Planner instead.
Run the following command in your session prior to execution:
set optimizer=off;
Resolution
This issue is permanently resolved in VMware Tanzu Greenplum Release 7.4.1 and later
In the patched versions, GPORCA now correctly checks for support and only attempts to split queries using the supported ordered-set aggregates (percentile_disc, percentile_cont, and median).
Action required: Upgrade your Greenplum Database to version 7.4.1 or a newer release.
References
Feedback
