Dmitry Dolgov <9erthali...@gmail.com> writes:
>> On Thu, Apr 25, 2019 at 8:24 PM Tom Lane <t...@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,
Well, that's just coincidental for the case where the problem fdw_expr is
a Param. I haven't tried to figure out exactly what upper-path generation
thinks it should put into fdw_exprs, but is it really only Params?
Anyway, ideally we'd not have any entries in fdw_scan_tlist that don't
include at least one foreign Var, and then there can't be a false match.
regards, tom lane
