EvalPlanQual behaves oddly for FDW queries involving system columns
От | Etsuro Fujita |
---|---|
Тема | EvalPlanQual behaves oddly for FDW queries involving system columns |
Дата | |
Msg-id | 54B7691B.5080702@lab.ntt.co.jp обсуждение исходный текст |
Ответы |
Re: EvalPlanQual behaves oddly for FDW queries involving
system columns
Re: EvalPlanQual behaves oddly for FDW queries involving system columns |
Список | pgsql-hackers |
Here is an example using postgres_fdw. [Terminal 1] postgres=# create table t (a int, b int); CREATE TABLE postgres=# insert into t values (1, 1); INSERT 0 1 postgres=# begin; BEGIN postgres=# update t set b = b * 2; UPDATE 1 [Terminal 2] postgres=# create foreign table ft (a int) server loopback options (table_name 'lbt'); CREATE FOREIGN TABLE postgres=# insert into ft values (1); INSERT 0 1 postgres=# select tableoid, ctid, * from ft; tableoid | ctid | a ----------+-------+--- 25092 | (0,1) | 1 (1 row) postgres=# select ft.tableoid, ft.ctid, ft.* from t, ft where t.a = ft.a for update; [Terminal 1] postgres=# commit; COMMIT [Terminal 2] postgres=# select ft.tableoid, ft.ctid, ft.* from t, ft where t.a = ft.a for update; tableoid | ctid | a ----------+----------------+--- 0 | (4294967295,0) | 1 (1 row) Note that tableoid and ctid have been changed! I think the reason for that is because EvalPlanQualFetchRowMarks doesn't properly set tableoid and ctid for foreign tables, IIUC. I think this should be fixed. Please find attached a patch. The patch slightly relates to [1], so if it is reasonable, I'll update [1] on top of this. [1] https://commitfest.postgresql.org/action/patch_view?id=1386 Best regards, Etsuro Fujita
Вложения
В списке pgsql-hackers по дате отправления: