Re: BUG #15781: subselect on foreign table (postgres_fdw) can crash (segfault)
Etsuro Fujita <etsuro.fujita@gmail.com>
From: Etsuro Fujita <etsuro.fujita@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>,
sean.johnston@edgeintelligence.com, pgsql-bugs@lists.postgresql.org, pgsql-hackers@lists.postgresql.org
Date: 2019-04-27T13:30:37Z
Lists: pgsql-bugs, pgsql-hackers
On Sat, Apr 27, 2019 at 2:10 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > (2019/04/26 3:24), Tom Lane wrote: > >> If we do leave it like this, then the only way for postgres_fdw to > >> avoid trouble is to not have any entries in fdw_exprs that exactly > >> match entries in fdw_scan_tlist. So that pretty much devolves back > >> to what I said before: don't ship values to the far end that are > >> just going to be fed back as-is. But now it's a correctness > >> requirement not just an optimization. > Well, the releases are coming up fast, so I spent some time on this. > 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. > We end up with slightly weird-looking plans if the troublesome Param > is actually a GROUP BY expression, but if it's not, I think things > are fine. Maybe we could do something smarter about the GROUP BY case, > but it seems weird enough to maybe not be worth additional trouble. Agreed. Thanks for working on this! Best regards, Etsuro Fujita
Commits
-
Avoid postgres_fdw crash for a targetlist entry that's just a Param.
- c25e638b1800 10.8 landed
- 8cad5adb9c0b 12.0 landed
- 1bf52d68800e 11.3 landed