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  (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>)
Список 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 по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: improving speed of make check-world
Следующее
От: Abhijit Menon-Sen
Дата:
Сообщение: Re: MD5 authentication needs help -SCRAM