Re: BUG #15781: subselect on foreign table (postgres_fdw) can crash (segfault)

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Dmitry Dolgov <9erthalion6@gmail.com>
Cc: sean.johnston@edgeintelligence.com, pgsql-bugs@lists.postgresql.org, PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Date: 2019-04-25T20:27:35Z
Lists: pgsql-bugs, pgsql-hackers
Dmitry Dolgov <9erthalion6@gmail.com> writes:
>> 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,

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



Commits

  1. Avoid postgres_fdw crash for a targetlist entry that's just a Param.