Re: BUG #15781: subselect on foreign table (postgres_fdw) can crash (segfault)

Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp> writes:
> (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.

> I worked on the ORDERED/FINAL-upperrel pushdown for PG12, but I don't 
> think that that's directly related to this issue, because this arises in 
> PG11 already.  Maybe I'm missing something, but the 
> UPPERREL_GROUP_AGG-upperrel pushdown added in PG10 is likely to be 
> related to this.  I'll work on this issue unless somebody wants to.  But 
> I'll take a 10-day vocation from tomorrow, so I don't think I'll be able 
> to fix this in the next minor release...

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.  See attached.

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.

			regards, tom lane