Re: [sqlsmith] Failed assertion in postgres_fdw/deparse.c:1116

On Tue, Jun 7, 2016 at 11:36 AM, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp
> wrote:

> On 2016/06/05 23:01, Andreas Seltenreich wrote:
> > Creating some foreign tables via postgres_fdw in the regression db of
> > master as of de33af8, sqlsmith triggers the following assertion:
> >
> > TRAP: FailedAssertion("!(((((const Node*)(var))->type) == T_Var))",
> File: "deparse.c", Line: 1116)
> >
> > gdb says var is holding a T_PlaceHolderVar instead. In a build without
> > assertions, it leads to an error later:
> >
> > ERROR: cache lookup failed for type 0
> >
> > Recipe:
> >
> > --8<---------------cut here---------------start------------->8---
> > create extension postgres_fdw;
> > create server myself foreign data wrapper postgres_fdw;
> > create schema fdw_postgres;
> > create user mapping for public server myself options (user :'USER');
> > import foreign schema public from server myself into fdw_postgres;
> > select subq_0.c0 as c0 from
> > (select 31 as c0 from fdw_postgres.a as ref_0
> > where 93 >= ref_0.aa) as subq_0
> > right join fdw_postgres.rtest_vview5 as ref_1
> > on (subq_0.c0 = ref_1.a )
> > where 92 = subq_0.c0;
> > --8<---------------cut here---------------end--------------->8---
>

The repro assumes existence of certain tables/views e.g. rtest_vview5, a in
public schema. Their definition is not included here. Although I could
reproduce the issue by adding a similar query in the postgres_fdw
regression tests (see attached patch).

>
> Thanks for the example. It seems that postgres_fdw join-pushdown logic
> (within foreign_join_ok()?) should reject a join if any PlaceHolderVars in
> its targetlist are required above it. Tried to do that with the attached
> patch which trivially fixes the reported assertion failure.
>

Although the patch fixes the issue, it's restrictive. The placeholder Vars
can be evaluated locally after the required columns are fetched from the
foreign server. The right fix, therefore, is to build targetlist containing
only the Vars that belong to the foreign tables, which in this case would
contain "nothing". Attached patch does this and fixes the issue, while
pushing down the join. Although, I haven't tried the exact query given in
the report. Please let me know if the patch fixes issue with that query as
well.

The query generated by sqlsmith doesn't seem to return any result since it
assigns 31 to subq_0.c0 and the WHERE clause checks 92 =subq_0.c0. Is that
expected?

--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company