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
-
Invalidate cached plans on FDW option changes.
- e4380e4cf68a 9.4.11 landed
- c52d37c8b367 10.0 landed
- aaf12e577ee9 9.5.6 landed
- a8191800a6e6 9.3.16 landed
- 4103a2f200d6 9.6.2 landed