On Mon, Apr 4, 2016 at 11:24 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Amit Langote <langote_amit...@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 -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers