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

Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)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