Re: EvalPlanQual behaves oddly for FDW queries involving system columns

Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp> writes:
> Let me explain further.  Here is the comment in ExecOpenScanRelation:

>       * Determine the lock type we need.  First, scan to see if target 
> relation
>       * is a result relation.  If not, check if it's a FOR UPDATE/FOR SHARE
>       * relation.  In either of those cases, we got the lock already.

> I think this is not true for foreign tables selected FOR UPDATE/SHARE, 
> which have markType = ROW_MARK_COPY, because such foreign tables don't 
> get opened/locked by InitPlan.  Then such foreign tables don't get 
> locked by neither of InitPlan nor ExecOpenScanRelation.  I think this is 
> a bug.

You are right.  I think it may not matter in practice, but if the executor
is taking its own locks here then it should not overlook ROW_MARK_COPY
cases.

> To fix it, I think we should open/lock such foreign tables at 
> InitPlan as the original patch does.

I still don't like that; InitPlan is not doing something that would
require physical table access.  The right thing is to fix
ExecOpenScanRelation's idea of whether InitPlan took a lock or not,
which I've now done.
        regards, tom lane