On 2015/03/25 4:56, Tom Lane wrote:
> 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.
OK, thanks.
Best regards,
Etsuro Fujita
