> On Thu, Apr 25, 2019 at 8:24 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> The proximate cause of the crash is that we have {PARAM 1}
> (representing the output of the InitPlan) in the path's fdw_exprs, and
> also the identical expression in fdw_scan_tlist, and that means that when
> setrefs.c processes the ForeignScan node it thinks it should replace the
> {PARAM 1} in fdw_exprs with a Var representing a reference to the
> fdw_scan_tlist entry.
I've noticed, that it behaves like that since f9f63ed1f2e5 (originally I found
it pretty strange, but after this explanation it does make sense). As an
experiment, I've changed the position of condition of
if (context->subplan_itlist->has_non_vars)
back - it also made problem to disappear, and what was interesting is that the
test case for update (exactly what this commit was fixing) is not crashing
either. I've checked on the commit right before f9f63ed1f2e5, without mentioned
reordering there is a crash, but I couldn't reproduce it on the master.