Re: BUG #17606: There is still some glitch in 3f7323cbb fixing failure of MULTIEXPR_SUBLINK - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #17606: There is still some glitch in 3f7323cbb fixing failure of MULTIEXPR_SUBLINK
Date
Msg-id 2452776.1662398393@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #17606: There is still some glitch in 3f7323cbb fixing failure of MULTIEXPR_SUBLINK  ("Andre Lin" <857348270@qq.com>)
List pgsql-bugs
"=?ISO-8859-1?B?QW5kcmUgTGlu?=" <857348270@qq.com> writes:
> > After contemplating that for awhile, by far the least painful way
> > seems to be to add the subLinkId to struct SubPlan.  We can get
> > away with that in the back branches as long as we add it at the
> > end, since SubPlans don't get recorded in the catalogs.

> But let's assume that we manage to verify initplan/subplan by adding
> subLinkId to SubPlan, we still have problem. In short, the exact
> subqueryid of the new MULTIEXPR Param will be pain in the ass...

Well, yeah, that data structure would need to change.

            regards, tom lane



pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #17607: Server process crashes when PLpgSQL function raises error in subtransaction
Next
From: Dmitriy Kuzmin
Date:
Subject: Re: Startup process on a hot standby crashes with an error "invalid memory alloc request size 1073741824" while replaying "Standby/LOCK" records