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: 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-04 08:45:01
Message-ID: 5702298D.4090903@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 Content-Type Size
cache-inval-ft-options-1.patch text/x-diff 662 bytes

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2016-04-04 08:58:31 Re: Move PinBuffer and UnpinBuffer to atomics
Previous Message Fujii Masao 2016-04-04 08:28:07 Re: Support for N synchronous standby servers - take 2