Why MemoryContextSwitch in ExecRelCheck ? - Mailing list pgsql-hackers

From Holger Krug
Subject Why MemoryContextSwitch in ExecRelCheck ?
Date
Msg-id 20020107085916.A1260@dev12.rationalizer.com
Whole thread Raw
Responses Re: Why MemoryContextSwitch in ExecRelCheck ?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Can anybody explain the following code detail ?

A comment in execMain.c tells us:

--start code snippet--* NB: the CurrentMemoryContext when this is called must be the context* to be used as the
per-querycontext for the query plan.      ExecutorRun()* and ExecutorEnd() must be called in this same memory context.*
----------------------------------------------------------------*/
TupleDesc
ExecutorStart(QueryDesc *queryDesc, EState *estate)
--end code snippet--

Nevertheless in ExecRelCheck a context switch to per-query memory
context is made:

--start code snippet--       /*        * If first time through for this result relation, build expression        *
nodetreesfor rel's constraint expressions.  Keep them in the        * per-query memory context so they'll survive
throughoutthe query.        */       if (resultRelInfo->ri_ConstraintExprs == NULL)       {               oldContext =
MemoryContextSwitchTo(estate->es_query_cxt);              resultRelInfo->ri_ConstraintExprs =
(List**) palloc(ncheck * sizeof(List *));               for (i = 0; i < ncheck; i++)               {
  qual = (List *) stringToNode(check[i].ccbin);                       resultRelInfo->ri_ConstraintExprs[i] = qual;
        }               MemoryContextSwitchTo(oldContext);       }
 
--end code snippet--

Is this a switch from per-query memory context to per-query memory
context, hence not necessary, or do I miss something ?

-- 
Holger Krug
hkrug@rationalizer.com


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: LWLock contention: I think I understand the problem
Next
From: Tom Lane
Date:
Subject: Re: Why MemoryContextSwitch in ExecRelCheck ?