Re: postgres_fdw : altering foreign table not invalidating prepare statement execution plan.

Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>

From: Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>
To: Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>
Cc: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>, Tom Lane <tgl@sss.pgh.pa.us>, Amit Langote <amitlangote09@gmail.com>, Rajkumar Raghuwanshi <rajkumar.raghuwanshi@enterprisedb.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2016-09-29T16:09:27Z
Lists: pgsql-hackers
>
>> The attached patch adds the
>> dependencies from create_foreignscan_plan() which is called for any
>> foreign access. I have also added testcases to test the functionality.
>> Let me know your comments on the patch.
>
>
> Hmm.  I'm not sure that that's a good idea.
>
> I was thinking the changes to setrefs.c proposed by Amit to collect that
> dependencies would be probably OK, but I wasn't sure that it's a good idea
> that he used PlanCacheFuncCallback as the syscache inval callback function
> for the foreign object caches because it invalidates not only generic plans
> but query trees, as you mentioned downthread.  So, I was thinking to modify
> his patch so that we add a new syscache inval callback function for the
> caches that is much like PlanCacheFuncCallback but only invalidates generic
> plans.

PlanCacheFuncCallback() invalidates the query tree only when
invalItems are added to the plan source. The patch adds the
dependencies in root->glob->invalItems, which standard_planner()
copies into PlannedStmt::invalItems. This is then copied into the
gplan->stmt_list. Thus PlanCacheFuncCallback never invalidates the
query tree. I have verified this under the debugger. Am I missing
something?

-- 
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company


Commits

  1. Invalidate cached plans on FDW option changes.