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

From: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Amit Langote <amitlangote09(at)gmail(dot)com>
Cc: Rajkumar Raghuwanshi <rajkumar(dot)raghuwanshi(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: postgres_fdw : altering foreign table not invalidating prepare statement execution plan.
Date: 2016-04-14 07:30:30
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 2016/04/05 14:24, Amit Langote wrote:
> On 2016/04/05 0:23, Tom Lane wrote:
>> Amit Langote <amitlangote09(at)gmail(dot)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:


In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2016-04-14 07:40:56 Re: Support for N synchronous standby servers - take 2
Previous Message Andres Freund 2016-04-14 06:31:21 Re: [COMMITTERS] pgsql: Allow Pin/UnpinBuffer to operate in a lockfree manner.