At Mon, 04 Apr 2016 11:23:34 -0400, Tom Lane <t...@sss.pgh.pa.us> wrote in <9798.1459783...@sss.pgh.pa.us> > Amit Langote <amitlangot...@gmail.com> writes: > > On Mon, Apr 4, 2016 at 11:24 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > >> 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? > > Hm, so we'd expect that whenever an FDW consulted the options while > making a plan, it'd have to record a plan dependency on them? That > would be a clean fix maybe, but I'm worried that third-party FDWs > would fail to get the word about needing to do this.
If the "recording" means recoding oids to CachedPlanSource like relationOids, it seems to be able to be recorded automatically by the core, not by fdw side, we already know the server id for foreign tables. I'm missing something? regards, -- Kyotaro Horiguchi NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
