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

From: Richard Guo <guofenglinux(at)gmail(dot)com>
To: 857348270(at)qq(dot)com, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: BUG #17606: There is still some glitch in 3f7323cbb fixing failure of MULTIEXPR_SUBLINK
Date: 2022-09-05 14:25:15
Message-ID: CAMbWs49A0FwQKq=_3pn6tRJqG5E_Y4uiUj9zAtuNbS0cTMYZ_A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Mon, Sep 5, 2022 at 3:33 PM PG Bug reporting form <noreply(at)postgresql(dot)org>
wrote:

> 3f7323cbb regenerates its Param for each SubPlan by traversing the
> targetlist. But ignore one point: initplan is not in targetlist.
> This will result in a failed assertion, or an error like "unexpected
> PARAM_MULTIEXPR ID: 131074"

Since initplan SubPlans do not have args lists, I think it's OK for them
to share output parameters. So maybe we do not need to do the
SS_make_multiexprs_unique trick for initplan SubPlans?

Thanks
Richard

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Richard Guo 2022-09-05 14:48:02 Re: BUG #17606: There is still some glitch in 3f7323cbb fixing failure of MULTIEXPR_SUBLINK
Previous Message David Rowley 2022-09-05 12:13:13 Re: Startup process on a hot standby crashes with an error "invalid memory alloc request size 1073741824" while replaying "Standby/LOCK" records