Re: postgres_fdw : altering foreign table not invalidating prepare statement execution plan.
От | Michael Paquier |
---|---|
Тема | Re: postgres_fdw : altering foreign table not invalidating prepare statement execution plan. |
Дата | |
Msg-id | CAB7nPqQu1_8=85raPjYkdQBp3z+EHETiVXnDZ9EQ9d_E=m7eSA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: postgres_fdw : altering foreign table not invalidating prepare statement execution plan. (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>) |
Список | pgsql-hackers |
On Fri, Sep 30, 2016 at 1:09 AM, Ashutosh Bapat <ashutosh.bapat@enterprisedb.com> wrote: >> >>> 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? Moved to next CF. Feel free to continue the work on this item. -- Michael
В списке pgsql-hackers по дате отправления: