Re: EvalPlanQual behaves oddly for FDW queries involving system columns - Mailing list pgsql-hackers

From Ashutosh Bapat
Subject Re: EvalPlanQual behaves oddly for FDW queries involving system columns
Date
Msg-id CAFjFpRc3ie8-2ug3+RL7xOWyq_S4=jkNUnWF6uPpuLSdYzLmLw@mail.gmail.com
Whole thread Raw
In response to Re: EvalPlanQual behaves oddly for FDW queries involving system columns  (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>)
Responses Re: EvalPlanQual behaves oddly for FDW queries involving system columns  (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>)
List pgsql-hackers
Hi Fujita-san,
I tried reproducing the issue with the steps summarised.
Here's my setup
postgres=# \d ft
         Foreign table "public.ft"
 Column |  Type   | Modifiers | FDW Options
--------+---------+-----------+-------------
 a      | integer |           |
Server: loopback
FDW Options: (table_name 'lbt')

postgres=# \d lbt
      Table "public.lbt"
 Column |  Type   | Modifiers
--------+---------+-----------
 a      | integer |

The select (without for update) returns me two rows (one inserted in lbt and one in ft), whereas in your description there is only one row. For me, I am getting following error
postgres=# select ft.tableoid, ft.ctid, ft.* from lbt, ft where lbt.a = ft.a
for update;
ERROR:  could not serialize access due to concurrent update
CONTEXT:  Remote SQL command: SELECT a, ctid FROM public.lbt FOR UPDATE
postgres=#

after commit on terminal 1.

Am I missing something?
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: improving speed of make check-world
Next
From: Abhijit Menon-Sen
Date:
Subject: Re: MD5 authentication needs help -SCRAM