Re: BUG #17606: There is still some glitch in 3f7323cbb fixing failure of MULTIEXPR_SUBLINK

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: BUG #17606: There is still some glitch in 3f7323cbb fixing failure of MULTIEXPR_SUBLINK
Дата
Msg-id 2452776.1662398393@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: BUG #17606: There is still some glitch in 3f7323cbb fixing failure of MULTIEXPR_SUBLINK  ("Andre Lin" <857348270@qq.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: BUG #17607: Server process crashes when PLpgSQL function raises error in subtransaction
Следующее
От: Dmitriy Kuzmin
Дата:
Сообщение: Re: Startup process on a hot standby crashes with an error "invalid memory alloc request size 1073741824" while replaying "Standby/LOCK" records