54001

At a glance

54001 covers a statement that exceeds a planner, parser, or execution-stack limit. Fixed paths include the 4096 grouping-set ceiling and max_stack_depth enforcement.

Meaning

The source separates a structural query limit (too many grouping sets present (maximum 4096)) from recursive execution depth (stack depth limit exceeded) with a hint naming max_stack_depth. They need different repairs: reducing query structure is not the same as changing a stack setting.

Diagnosis

Preserve the message and phase. For grouping sets, count the generated grouping sets and simplify the query. For stack depth, inspect recursive SQL/function expansion and compare the setting with the platform stack limit before changing it.

Response

Rewrite or decompose a structurally excessive statement. For stack depth, remove unintended recursion or reduce nesting; change max_stack_depth only after checking the operating-system stack allowance and operational policy. If this ERROR occurs inside an explicit transaction, use ROLLBACK or ROLLBACK TO SAVEPOINT before retrying; in autocommit, retry only after the statement or stack setting is corrected. The GUC rlimit check validates a SET or configuration value against the platform allowance; a failed SET still follows the transaction context that issued it. Validate the rewritten statement rather than automatically replaying it.

Versions

The locked catalogue records this condition from 7.4; cited parser and stack-depth paths are PostgreSQL 18.6 source. No complexity limit was forced.

Related

54000, 54011, 42601

Sources

src/backend/parser/parse_agg.c#L1166-L1172

src/backend/utils/misc/stack_depth.c#L100-L105

src/backend/utils/misc/stack_depth.c#L156-L168

The structured evidence record records fixed messages and the source/runtime boundary.