Re: EvalPlanQual behaves oddly for FDW queries involving system columns

From: Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>
To: Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: EvalPlanQual behaves oddly for FDW queries involving system columns
Date: 2015-03-09 07:02:24
Message-ID: CAFjFpRc3ie8-2ug3+RL7xOWyq_S4=jkNUnWF6uPpuLSdYzLmLw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Abhijit Menon-Sen 2015-03-09 07:21:38 Re: MD5 authentication needs help -SCRAM
Previous Message Michael Paquier 2015-03-09 06:51:15 Re: improving speed of make check-world