Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commit7c1719b

Browse files
committed
Fix handling of data-modifying CTE subplans in EvalPlanQual.
We can't just skip initializing such subplans, because the referencing CTEnode will expect to find the subplan available when it initializes. Thatin turn means that ExecInitModifyTable must allow the case (which actuallyit needed to do anyway, since there's no guarantee that ModifyTable isexactly at the top of the CTE plan tree). So move the complaint about notbeing allowed in EvalPlanQual mode to execution instead of initialization.Testing turned up yet another problem, which is that we'd try tore-initialize the result relation's index list, leading to leaks anddangling pointers.Per report from Phil Sorber. Back-patch to 9.1 where data-modifying CTEswere introduced.
1 parent672614c commit7c1719b

File tree

2 files changed

+19
-20
lines changed

2 files changed

+19
-20
lines changed

‎src/backend/executor/execMain.c

Lines changed: 2 additions & 11 deletions
Original file line numberDiff line numberDiff line change
@@ -2347,24 +2347,15 @@ EvalPlanQualStart(EPQState *epqstate, EState *parentestate, Plan *planTree)
23472347
* ExecInitSubPlan expects to be able to find these entries. Some of the
23482348
* SubPlans might not be used in the part of the plan tree we intend to
23492349
* run, but since it's not easy to tell which, we just initialize them
2350-
* all. (However, if the subplan is headed by a ModifyTable node, then it
2351-
* must be a data-modifying CTE, which we will certainly not need to
2352-
* re-run, so we can skip initializing it.This is just an efficiency
2353-
* hack; it won't skip data-modifying CTEs for which the ModifyTable node
2354-
* is not at the top.)
2350+
* all.
23552351
*/
23562352
Assert(estate->es_subplanstates==NIL);
23572353
foreach(l,parentestate->es_plannedstmt->subplans)
23582354
{
23592355
Plan*subplan= (Plan*)lfirst(l);
23602356
PlanState*subplanstate;
23612357

2362-
/* Don't initialize ModifyTable subplans, per comment above */
2363-
if (IsA(subplan,ModifyTable))
2364-
subplanstate=NULL;
2365-
else
2366-
subplanstate=ExecInitNode(subplan,estate,0);
2367-
2358+
subplanstate=ExecInitNode(subplan,estate,0);
23682359
estate->es_subplanstates=lappend(estate->es_subplanstates,
23692360
subplanstate);
23702361
}

‎src/backend/executor/nodeModifyTable.c

Lines changed: 17 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -715,6 +715,18 @@ ExecModifyTable(ModifyTableState *node)
715715
ItemPointerDatatuple_ctid;
716716
HeapTupleHeaderoldtuple=NULL;
717717

718+
/*
719+
* This should NOT get called during EvalPlanQual; we should have passed a
720+
* subplan tree to EvalPlanQual, instead. Use a runtime test not just
721+
* Assert because this condition is easy to miss in testing. (Note:
722+
* although ModifyTable should not get executed within an EvalPlanQual
723+
* operation, we do have to allow it to be initialized and shut down in
724+
* case it is within a CTE subplan. Hence this test must be here, not in
725+
* ExecInitModifyTable.)
726+
*/
727+
if (estate->es_epqTuple!=NULL)
728+
elog(ERROR,"ModifyTable should not be called during EvalPlanQual");
729+
718730
/*
719731
* If we've already completed processing, don't try to do more. We need
720732
* this test because ExecPostprocessPlan might call us an extra time, and
@@ -892,14 +904,6 @@ ExecInitModifyTable(ModifyTable *node, EState *estate, int eflags)
892904
/* check for unsupported flags */
893905
Assert(!(eflags& (EXEC_FLAG_BACKWARD |EXEC_FLAG_MARK)));
894906

895-
/*
896-
* This should NOT get called during EvalPlanQual; we should have passed a
897-
* subplan tree to EvalPlanQual, instead. Use a runtime test not just
898-
* Assert because this condition is easy to miss in testing ...
899-
*/
900-
if (estate->es_epqTuple!=NULL)
901-
elog(ERROR,"ModifyTable should not be called during EvalPlanQual");
902-
903907
/*
904908
* create state structure
905909
*/
@@ -947,9 +951,13 @@ ExecInitModifyTable(ModifyTable *node, EState *estate, int eflags)
947951
* descriptors in the result relation info, so that we can add new
948952
* index entries for the tuples we add/update.We need not do this
949953
* for a DELETE, however, since deletion doesn't affect indexes.
954+
* Also, inside an EvalPlanQual operation, the indexes might be open
955+
* already, since we share the resultrel state with the original
956+
* query.
950957
*/
951958
if (resultRelInfo->ri_RelationDesc->rd_rel->relhasindex&&
952-
operation!=CMD_DELETE)
959+
operation!=CMD_DELETE&&
960+
resultRelInfo->ri_IndexRelationDescs==NULL)
953961
ExecOpenIndices(resultRelInfo);
954962

955963
/* Now init the plan for this result rel */

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp