Re: EvalPlanQual behaves oddly for FDW queries involving system columns

On 4/14/15 1:05 AM, Kyotaro HORIGUCHI wrote:
> As an example, the following operations cause an "unexpected"
> result.
>
> Ex. 1
> Session A=# create table t (a int primary key, b int);
> Session A=# insert into t (select a, 1 from generate_series(0, 99) a);
> Session A=# begin;
> Session A=# select * from t where a = 1 for no key update;
>
> Session B=# begin;
> Session B=# select * from t where a = 1 for key share;
> Session B=# update t set a = -a where a = 1;
> <session B is blocked>
>
> Ex. 2
> Session A=# create table t (a int, b int); -- a is the key in mind.
> Session A=# insert into t (select a, 1 from generate_series(0, 99) a);
> Session A=# begin;
> Session A=# select * from t where a = 1 for no key update;
>
> Session B=# begin;
> Session B=# select * from t where a = 1 for key share;
>
> Session A=# update t set a = -a where a = 1;
> UPDATE 1
> Session A=# commit;
>
> Session B=# select * from t where a = 1;
> (0 rows)  -- Woops.

Those results are indeed surprising, but since we allow it in a direct 
connection I don't see why we wouldn't allow it in the Postgres FDW...

As for the FDW not knowing about keys, why would it need to? If you try 
to do something illegal it's the remote side that should throw the 
error, not the FDW.

Of course, if you try to do a locking operation on an FDW that doesn't 
support it, the FDW should throw an error... but that's different.
-- 
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com