You signed in with another tab or window.Reload to refresh your session.You signed out in another tab or window.Reload to refresh your session.You switched accounts on another tab or window.Reload to refresh your session.Dismiss alert
Ensure first ModifyTable rel initialized if all are pruned
Commitcbc1279 introduced tracking of unpruned relids to avoidprocessing pruned relations, and changed ExecInitModifyTable() toinitialize only unpruned result relations. As a result, MERGEstatements that prune all target partitions can now lead to crashesor incorrect behavior during execution.The crash occurs because some executor code paths rely onModifyTableState.resultRelInfo[0] being present and initialized,even when no result relations remain after pruning. For example,ExecMerge() and ExecMergeNotMatched() use the first resultRelInfoto determine the appropriate action. Similarly,ExecInitPartitionInfo() assumes that at least one result relationexists.To preserve these assumptions, ExecInitModifyTable() now includes thefirst result relation in the initialized result relation list if allresult relations for that ModifyTable were pruned. To enable that,ExecDoInitialPruning() ensures the first relation is locked if it waspruned and locking is necessary.To support this exception to the pruning logic, PlannedStmt nowincludes a list of RT indexes identifying the first result relationof each ModifyTable node in the plan. This allowsExecDoInitialPruning() to check whether each such relation waspruned and, if so, lock it if necessary.Bug: #18830Reported-by: Robins Tharakan <tharakan@gmail.com>Diagnozed-by: Tender Wang <tndrwang@gmail.com>Diagnozed-by: Dean Rasheed <dean.a.rasheed@gmail.com>Co-authored-by: Dean Rasheed <dean.a.rasheed@gmail.com>Reviewed-by: Tender Wang <tndrwang@gmail.com>Reviewed-by: Dean Rasheed <dean.a.rasheed@gmail.com>Discussion:https://postgr.es/m/18830-1f31ea1dc930d444%40postgresql.org