| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andre Lin <857348270(at)qq(dot)com> |
| Cc: | pgsql-bugs <pgsql-bugs(at)lists(dot)postgresql(dot)org>, guofenglinux <guofenglinux(at)gmail(dot)com> |
| Subject: | Re: BUG #17606: There is still some glitch in 3f7323cbb fixing failure of MULTIEXPR_SUBLINK |
| Date: | 2022-09-05 17:19:53 |
| Message-ID: | 2452776.1662398393@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
"=?ISO-8859-1?B?QW5kcmUgTGlu?=" <857348270(at)qq(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dmitriy Kuzmin | 2022-09-06 06:38:43 | Re: Startup process on a hot standby crashes with an error "invalid memory alloc request size 1073741824" while replaying "Standby/LOCK" records |
| Previous Message | Tom Lane | 2022-09-05 17:16:19 | Re: BUG #17607: Server process crashes when PLpgSQL function raises error in subtransaction |