#287 Error in queries involving joins and FOR UPDATE

[Abbas Butt]

create table t1(val int, val2 int) distribute by modulo(val);
create table t2(val int, val2 int) distribute by modulo(val);

insert into t1 values(1,11),(2,11);
insert into t2 values(1,11),(2,11);

select * from t1, t2 where t1.val = t2.val for update;

results in

ERROR: could not read block 0 in file "base/16386/16387": read only 0 of 8192 bytes

[Abbas Butt]

Commit 05375e85426e55f11b45a13e0804f51d3223d8c5 fixes this issue.

Here is the commit message

Add support for FOR UPDATE/SHARE

This comit fixes bug ID 3515041

The queries containing FOR UPDATE/SAHRE were not working because coordinator was
trying to lock rows where as in fact data node is supposed to do it since rows do
not exist on the coordinator. Coordinator should therefore not try to execute row
marks in PG way, instead it should silently pass on the FOR UPDATE/SHARE clauses
to the data node.
To implement we used the following technique.
On coordinators we have divided row marks in two groups.
Group One of type FOR UPDATE & SHARE and
Group Two of the rest of the types.
Second group is handled in PG way both on coordinator and data node,
however first group is handled on coordinators in such a way that it
only serves to produce the correct clause in the remote query.

The downside of this approach is that we would un-necessarily lock
complete tables on data nodes, where as we should have locked only a subset.

Test cases are included in the patch.