Re: BUG #18657: Using JSON_OBJECTAGG with volatile function leads to segfault

Поиск
Список
Период
Сортировка
От Tender Wang
Тема Re: BUG #18657: Using JSON_OBJECTAGG with volatile function leads to segfault
Дата
Msg-id CAHewXNkcG=adJtfqHXuLnZrDAfSWPrX0GwLU98hYLjJbgZON1A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: BUG #18657: Using JSON_OBJECTAGG with volatile function leads to segfault  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: BUG #18657: Using JSON_OBJECTAGG with volatile function leads to segfault
Список pgsql-bugs


Tom Lane <tgl@sss.pgh.pa.us> 于2024年10月18日周五 04:30写道:
Amit Langote <amitlangote09@gmail.com> writes:
> On Thu, Oct 17, 2024 at 1:12 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> In the short term, I suspect the only workable fix is to undo the
>> optimization of having ExecInitExprRec not recurse into both raw_expr
>> and formatted_expr.

> This or actually I'm tempted to simply revert the whole thing
> (b6e1157e7d3) as an ill-considered refactoring, because I am not able
> to convince myself that calling ExecAggPlainTransByVal() twice, via
> both raw_expr and formatted_expr, is always safe.

Not following the concern here?  As far as nodeAgg is concerned,
they'd be two independent aggregates.

In any case, whatever we do in master, you can't "simply revert"
b6e1157e7 in released branches.  It changed the way JsonValueExpr is
represented in stored rules, and you don't get to undo that midstream.

Sorry, I can't fully understand what you said above. What's the stored rule? 
And "you don't get to undo that midstream."  What is the Scenario that we get to undo?
Can you give more explanation?  Thanks.

--
Thanks,
Tender Wang

В списке pgsql-bugs по дате отправления: