On 2016/04/05 14:24, Amit Langote wrote: > On 2016/04/05 0:23, Tom Lane wrote: >> Amit Langote <amitlangot...@gmail.com> writes: >>> 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. > > I would imagine that that level of granularity may be a little too much; I > mean tracking dependencies at the level of individual FDW/foreign > table/foreign server options. I think it should really be possible to do > the entire thing in core instead of requiring this to be made a concern of > FDW authors. How about the attached that teaches > extract_query_dependencies() to add a foreign table and associated foreign > data wrapper and foreign server to invalItems. Also, it adds plan cache > callbacks for respective caches. > > One thing that I observed that may not be all that surprising is that we > may need a similar mechanism for postgres_fdw's connection cache, which > doesn't drop connections using older server connection info after I alter > them. I was trying to test my patch by altering dbaname option of a > foreign server but that was silly, ;). Although, I did confirm that the > patch works by altering use_remote_estimates server option. I could not > really test for FDW options though. > > Thoughts?
I added this to next CF, just in case: https://commitfest.postgresql.org/10/609/ Thanks, Amit -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers