Ashutosh Bapat <ashutosh.bapat@enterprisedb.com> writes:
> I am seeing different results with two queries which AFAIU have same
> semantics and hence are expected to give same results.
> postgres=# select * from t1, (select distinct val, val2 from t2) t2ss where t1.val = t2ss.val for update of t1;
> postgres=# select * from t1, lateral (select distinct val, val2 from t2 where t2.val = t1.val) t2ss for update of
t1;
(I renamed your inline sub-selects to avoid confusion between them and the
table t2.)
I'm skeptical that those should be claimed to have identical semantics.
In the first example, after we've found the join row (1,1,1,1), we block
to see if the pending update on t1 will commit. After it does, we recheck
the join condition using the updated row from t1 (and the original row
from t2ss). The condition fails, so the updated row is not output.
The same thing happens in the second example, ie, we consider the updated
row from t1 and the non-updated row from t2ss (NOT t2). There are no join
conditions to recheck (in the outer query level), so the row passes, and
we output it.
If you'd allowed the FOR UPDATE to propagate into the sub-select, then the
sub-select's conditions would be considered as needing rechecks ... of
course, that would require removing the DISTINCT.
This example does show that a lateral reference to a FOR UPDATE table from
a non-FOR-UPDATE subselect has confusing behavior. Maybe we ought to
forbid that.
regards, tom lane
