Thread: Re: BUG #15781: subselect on foreign table (postgres_fdw) can crash (segfault)
Re: BUG #15781: subselect on foreign table (postgres_fdw) can crash (segfault)
From
Sean Johnston
Date:
Not sure if this is the right avenue to follow up on this. The patch works fine. However, we're working on a modified version of the postgres_fdw in which we're trying to push as much as possible to the remote nodes, including ordering and limits. The patch causes the upper paths for the ordering and limit to be rejected as they have no relids. I've had a quick look at maybe how to pull in relids in the fdw private data but its not obvious. Obviously this isn't mainstream postgres but just wondering if anyone has looked into issues with regards to pushing order/limit to remote nodes for fdw.
On Sat, Apr 27, 2019 at 3:47 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Etsuro Fujita <etsuro.fujita@gmail.com> writes:
> On Sat, Apr 27, 2019 at 2:10 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> If we don't want to change what the core code does with fdw_exprs,
>> I think the only way to fix it is to hack postgres_fdw so that it
>> won't generate plans involving the problematic case.
> Seems reasonable.
>> See attached.
> I read the patch. It looks good to me. I didn't test it, though.
Thanks for looking! Have a good vacation ...
regards, tom lane
Sean Johnston <sean.johnston@edgeintelligence.com> writes:
> Not sure if this is the right avenue to follow up on this. The patch works
> fine. However, we're working on a modified version of the postgres_fdw in
> which we're trying to push as much as possible to the remote nodes,
> including ordering and limits. The patch causes the upper paths for the
> ordering and limit to be rejected as they have no relids.
Uh, what? If you're speaking of 8cad5adb9, the only case I'm aware of
where it might be a performance issue is if you have "GROUP BY
local-expr", which seems like a pretty weird thing to need to push
to the remote side, since the local expression would be effectively
a constant on the far end.
You could imagine working around it by discarding such GROUP BY
columns in what's to be sent to the far end, and if you end up with
an empty GROUP BY clause, sending "HAVING TRUE" instead to keep the
semantics the same. But I'm uninterested in stacking yet more
klugery atop 8cad5adb9 so far as the community code is concerned.
The right way forward, as noted in the commit message, is to revert
that patch in favor of adding some API that will let the FDW control
how setrefs.c processes a ForeignScan's expressions. We just can't
do that in released branches :-(.
It's possible that we should treat this issue as an open item for v12
instead of letting it slide to v13 or later. But I think people would
only be amenable to that if you can point to a non-silly example where
failure to push the GROUP BY creates a performance issue.
regards, tom lane
Re: BUG #15781: subselect on foreign table (postgres_fdw) can crash (segfault)
From
Etsuro Fujita
Date:
On Sat, May 25, 2019 at 2:19 AM Sean Johnston <sean.johnston@edgeintelligence.com> wrote: > Obviously this isn't mainstream postgres but just wondering if anyone has looked into issues with regards to pushing order/limitto remote nodes for fdw. In PostgreSQL 12 Beta 1 released this week [1], we can push down ORDER BY/LIMIT to the remote PostgreSQL server. Give it a try! Best regards, Etsuro Fujita [1] https://www.postgresql.org/about/news/1943/