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
