From: Tom Lane <tgl@sss.pgh.pa.us>
To: Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>
Cc: srinivasan.sa@zohocorp.com
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #15613: Bug in PG Planner for Foreign Data Wrappers
Date: Thu, 07 Feb 2019 09:40:28 -0500
Message-ID: <18211.1549550428@sss.pgh.pa.us> (raw)
In-Reply-To: <5C5BE324.6030601@lab.ntt.co.jp>
References: <15613-092be1be9576c728@postgresql.org>
<5C51993C.2070606@lab.ntt.co.jp>
<19832.1548865557@sss.pgh.pa.us>
<24678.1548870484@sss.pgh.pa.us>
<5C52C769.5090600@lab.ntt.co.jp>
<19209.1548957996@sss.pgh.pa.us>
<5C5A5F75.5040203@lab.ntt.co.jp>
<5C5ACA1B.3000207@lab.ntt.co.jp>
<11975.1549480555@sss.pgh.pa.us>
<5C5BE324.6030601@lab.ntt.co.jp>
Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp> writes:
>> I propose that we apply this or something much like it to HEAD, and leave
>> the problem of actually working out parameterized foreign joins for later.
> Agreed. One thing I noticed is this bit in create_foreign_join_path:
> + /*
> + * Since the path's required_outer should always include all the rel's
> + * lateral_relids, forcibly add those if necessary. This is a bit of a
> + * hack, but up till early 2019 the contrib FDWs failed to ensure that,
> + * and it's likely that the same error has propagated into many external
> + * FDWs. Don't risk modifying the passed-in relid set here.
> + */
> + if (rel->lateral_relids && !bms_is_subset(rel->lateral_relids,
> + required_outer))
> + required_outer = bms_union(required_outer, rel->lateral_relids);
> I think this would waste cycles. Do we really need this? How about
> just throwing an error instead of doing this, if the joinrel has lateral
> references?
It ends up being the same thing, because of the test below it, but
at least in HEAD yes this could be simplified. What I posted is a bit
schizophrenic as to whether it's intended for HEAD or back branches.
Probably, in HEAD there is no good reason to cater for buggy FDWs at
all; the new Asserts in relnode.c are enough, assuming that FDW authors
run some tests while updating to v12. And if we decide not to backpatch
create_foreign_join_path at all, then it doesn't need a defense like the
above either. So we just need the above-quoted bit in the back branch
versions of create_foreignscan_path.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: tgl@sss.pgh.pa.us, fujita.etsuro@lab.ntt.co.jp, srinivasan.sa@zohocorp.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #15613: Bug in PG Planner for Foreign Data Wrappers
In-Reply-To: <18211.1549550428@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox