At Fri, 9 Oct 2015 18:40:32 +0900, Etsuro Fujita <fujita.ets...@lab.ntt.co.jp>
wrote in <56178b90.4030...@lab.ntt.co.jp>
> > What do you think the right behavior?
# 'is' was omitted..
> IIUC, I think that the foreign scan's slot should be set empty, that
Even for the case, EvalPlanQualFetchRowMarks retrieves tuples of
remote tables out of the whole-row resjunks and set them to
es_epqTuple so that EvalPlanQualNext can use it. The behavior
is not different from the 'FOR UPDATE;' (for all tables) cases.
I supposed that whole-row value for the joined tuple would be
treated in the same manner to the case of the tuples of base
This is because preprocess_rowmarks makes rowMarks of the type
LCS_NONE for the relations other than the designated by "OF
colref" for "FOR UPDATE". Then it is converted into ROW_MARK_COPY
by select_rowmark_type, which causes the behavior above, as the
default behavior for foreign tables.
> the join should fail, and that the updated version of the tuple in v
> should be ignored in that scenario since that for the updated version
> of the tuple in v, the tuples obtained from those two foreign tables
> wouldn't satisfy the remote query.
AFAICS, no updated version for remote tables are obtained.
Even though the behavior I described above is correct, the join
would fail, too. But it is because v.r is no longer equal to
bigft2.r in the whole-row-var tuples. This seems seemingly the
same behavior with that on local tables.
# LCS_NONE for local tables is converted into ROW_MARK_COPY if no
# securityQuals are attached.
> But if populating the foreign
> scan's slot from that column, then the join would success and the
> updated version of the tuple in v would be returned wrongly, I think.
I might understand wrongly in some points..
NTT Open Source Software Center
Sent via pgsql-hackers mailing list (firstname.lastname@example.org)
To make changes to your subscription: