At Mon, 04 Apr 2016 11:23:34 -0400, Tom Lane <tgl@sss.pgh.pa.us> wrote in <9798.1459783414@sss.pgh.pa.us>
> Amit Langote <amitlangote09@gmail.com> writes:
> > On Mon, Apr 4, 2016 at 11:24 PM, Tom Lane <tgl@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