On Tue, Apr 11, 2017 at 3:53 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > I wrote: >> Apparently, postgres_fdw is trying to store RestrictInfos in the >> fdw_private field of a ForeignScan node. That won't do; those aren't >> supposed to be present in a finished plan tree, so there's no readfuncs.c >> support for them (and we're not adding it). > >> Don't know if this is a new bug, or ancient but not previously reachable. >> It seems to be nearly the inverse of the problem you found yesterday, >> in which postgres_fdw was stripping RestrictInfos sooner than it really >> ought to. Apparently that whole business needs a fresh look. > > Attached is a proposed patch that cleans up the mess here --- and it was > a mess. The comments for PgFdwRelationInfo claimed that the remote_conds > and local_conds fields contained bare clauses, but actually they could > contain either bare clauses or RestrictInfos or both, depending on where > the clauses had come from. And there was some seriously obscure and > undocumented logic around how the fdw_recheck_quals got set up for a > foreign join node. (BTW, said logic is assuming that no EPQ recheck is > needed for a foreign join. I commented it to that effect, but I'm not > very sure that I believe it. If there's a bug there, though, it's > independent of the immediate problem.) > > Anybody want to review this, or shall I just push it? >
Will be reviewing it in a couple of hours. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
