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-11 08:37:55
Message-ID: CAFjFpRfo1wP0mWASYKQgSSudaRG_StQY1ZTZUvmmEJ_6hzVX6Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(dot)etsuro(at)lab(dot)ntt(dot)co(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2015-03-11 08:53:00 Re: pg_rewind in contrib
Previous Message Ilya Ashchepkov 2015-03-11 08:05:00 Re: mogrify and indent features for jsonb