On Mon, Apr 4, 2016 at 11:24 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Amit Langote <Langote_Amit_f8@lab.ntt.co.jp> writes:
>> On 2016/04/04 15:17, Rajkumar Raghuwanshi wrote:
>>> * .Observation: *Prepare statement execution plan is not getting changed
>>> even after altering foreign table to point to new schema.
>
>> I wonder if performing relcache invalidation upon ATExecGenericOptions()
>> is the correct solution for this problem. The attached patch fixes the
>> issue for me.
>
> A forced relcache inval will certainly fix it, but I'm not sure if that's
> the best (or only) place to put it.
>
> A related issue, now that I've seen this example, is that altering
> FDW-level or server-level options won't cause a replan either. I'm
> not sure there's any very good fix for that. Surely we don't want
> to try to identify all tables belonging to the FDW or server and
> issue relcache invals on all of them.
Hm, some kind of PlanInvalItem-based solution could work maybe? Or
some solution on lines of recent PlanCacheUserMappingCallback() added
by fbe5a3fb, wherein I see this comment which sounds like a similar
solution could be built for servers and FDWs:
+ /*
+ * If the plan has pushed down foreign joins, those join may become
+ * unsafe to push down because of user mapping changes. Invalidate only
+ * the generic plan, since changes to user mapping do not invalidate the
+ * parse tree.
+ */
Missing something am I?
Thanks,
Amit
