Re: postgres_fdw : altering foreign table not invalidating prepare statement execution plan. - Mailing list pgsql-hackers

From Amit Langote
Subject Re: postgres_fdw : altering foreign table not invalidating prepare statement execution plan.
Date
Msg-id 5702298D.4090903@lab.ntt.co.jp
Whole thread Raw
In response to postgres_fdw : altering foreign table not invalidating prepare statement execution plan.  (Rajkumar Raghuwanshi <rajkumar.raghuwanshi@enterprisedb.com>)
Responses Re: postgres_fdw : altering foreign table not invalidating prepare statement execution plan.  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hi,

Thanks for the report.

On 2016/04/04 15:17, Rajkumar Raghuwanshi wrote:
> Hi,
>
> I observed below in postgres_fdw
>
> * .Observation: *Prepare statement execution plan is not getting changed
> even after altering foreign table to point to new schema.
>

[ ... ]

> PREPARE stmt_ft AS select c1,c2 from ft;
>
> EXECUTE stmt_ft;
>  c1 |  c2
> ----+-------
>   1 | s1.lt
> (1 row)
>
> --changed foreign table ft pointing schema from s1 to s2
> ALTER foreign table ft options (SET schema_name 's2', SET table_name 'lt');
> ANALYZE ft;
>
> EXPLAIN (COSTS OFF, VERBOSE) EXECUTE stmt_ft;
>                QUERY PLAN
> ----------------------------------------
>  Foreign Scan on public.ft
>    Output: c1, c2
>    Remote SQL: SELECT c1, c2 FROM s1.lt
> (3 rows)

I wonder if performing relcache invalidation upon ATExecGenericOptions()
is the correct solution for this problem.  The attached patch fixes the
issue for me.

Thanks,
Amit

Attachment

pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: Support for N synchronous standby servers - take 2
Next
From: Andres Freund
Date:
Subject: Re: Move PinBuffer and UnpinBuffer to atomics