Re: EvalPlanQual behaves oddly for FDW queries involving system columns
| От | Ashutosh Bapat |
|---|---|
| Тема | Re: EvalPlanQual behaves oddly for FDW queries involving system columns |
| Дата | |
| Msg-id | CAFjFpRc3ie8-2ug3+RL7xOWyq_S4=jkNUnWF6uPpuLSdYzLmLw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: EvalPlanQual behaves oddly for FDW queries involving system columns (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>) |
| Ответы |
Re: EvalPlanQual behaves oddly for FDW queries involving
system columns
|
| Список | pgsql-hackers |
Hi Fujita-san,
I tried reproducing the issue with the steps summarised.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=#
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
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
В списке pgsql-hackers по дате отправления: