Re: bug report: some issues about pg_15_stable(8fa4a1ac61189efffb8b851ee77e1bc87360c445)
jian he <jian.universality@gmail.com>
From: jian he <jian.universality@gmail.com>
To: Dean Rasheed <dean.a.rasheed@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, zwj <sxzwj@vip.qq.com>, pgsql-hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-02-29T03:04:35Z
Lists: pgsql-hackers
On Wed, Feb 28, 2024 at 8:11 PM Dean Rasheed <dean.a.rasheed@gmail.com> wrote: > > On Wed, 28 Feb 2024 at 09:16, jian he <jian.universality@gmail.com> wrote: > > > > + oldcontext = MemoryContextSwitchTo(estate->es_query_cxt); > > + > > + node->as_epq_tupdesc = lookup_rowtype_tupdesc_copy(tupType, tupTypmod); > > + > > + ExecAssignExprContext(estate, &node->ps); > > + > > + node->ps.ps_ProjInfo = > > + ExecBuildProjectionInfo(castNode(Append, node->ps.plan)->epq_targetlist, > > + > > EvalPlanQualStart, EvalPlanQualNext will switch the memory context to > > es_query_cxt. > > so the memory context switch here is not necessary? > > > > Yes it is necessary. The EvalPlanQual mechanism switches to the > epqstate->recheckestate->es_query_cxt memory context, which is not the > same as the main query's estate->es_query_cxt (they're different > executor states). Most stuff allocated under EvalPlanQual() is > intended to be short-lived (just for the duration of that specific EPQ > check), whereas this stuff (the TupleDesc and Projection) is intended > to last for the duration of the main query, so that it can be reused > in later EPQ checks. > sorry for the noise. I understand it now. Another small question: for the Append case, we can set/initialize it at create_append_plan, all other elements are initialized there, why we set it at set_append_references. just wondering.
Commits
-
Fix handling of self-modified tuples in MERGE.
- 29ef1dd19b4f 17.0 landed
- dd73d10adf00 16.3 landed
- b5c645d2a265 15.7 landed
-
Sync PG_VERSION file in CREATE DATABASE.
- 8fa4a1ac6118 15.6 cited