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 CAFjFpRfo1wP0mWASYKQgSSudaRG_StQY1ZTZUvmmEJ_6hzVX6Q@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
List pgsql-hackers
Now I can reproduce the problem.

Sanity
--------
Patch compiles cleanly and make check passes. The tests in file_fdw and postgres_fdw contrib modules pass.

The patch works as expected in the test case reported.

I have only one doubt.
In EvalPlanQualFetchRowMarks(). tuple->t_self is assigned from td->t_ctid. CTID or even t_self may be valid for foreign tables based on postgres_fdw but may not be valid for other FDWs. So, this assignment might put some garbage in t_self, rather we should set it to invalid as done prior to the patch. I might have missed some previous thread, we decided to go this route, so ignore the comment, in that case.

Apart from this, I do not have any comments here.

On Mon, Mar 9, 2015 at 4:05 PM, Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp> wrote:
On 2015/03/09 16:02, Ashutosh Bapat wrote:
I tried reproducing the issue with the steps summarised.

Thanks for the review!

Here's my setup

Sorry, my explanation was not enough, but such was not my intention. I'll re-summarize the steps below:

[Create a test environment]

$ createdb mydatabase
$ psql mydatabase
mydatabase=# create table mytable (a int);

$ psql postgres
postgres=# create extension postgres_fdw;
postgres=# create server loopback foreign data wrapper postgres_fdw options (dbname 'mydatabase');
postgres=# create user mapping for current_user server loopback;
postgres=# create foreign table ftable (a int) server loopback options (table_name 'mytable');
postgres=# insert into ftable values (1);
postgres=# create table ltable (a int, b int);
postgres=# insert into ltable values (1, 1);

[Run concurrent transactions]

In terminal1:
$ psql postgres
postgres=# begin;
BEGIN
postgres=# update ltable set b = b * 2;
UPDATE 1

In terminal2:
$ psql postgres
postgres=# select tableoid, ctid, * from ftable;
 tableoid | ctid  | a
----------+-------+---
    16394 | (0,1) | 1
(1 row)

postgres=# select f.tableoid, f.ctid, f.* from ftable f, ltable l where f.a = l.a for update;

In terminal1:
postgres=# commit;
COMMIT

In terminal2:(When committing the UPDATE query in terminal1, psql in terminal2 will display the result for the SELECT-FOR-UPDATE query as shown below.)
 tableoid |      ctid      | a
----------+----------------+---
        0 | (4294967295,0) | 1
(1 row)

Best regards,
Etsuro Fujita



--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company

pgsql-hackers by date:

Previous
From: Ilya Ashchepkov
Date:
Subject: Re: mogrify and indent features for jsonb
Next
From: Heikki Linnakangas
Date:
Subject: Re: pg_rewind in contrib