From: | Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: EvalPlanQual behaves oddly for FDW queries involving system columns |
Date: | 2015-04-03 11:33:04 |
Message-ID: | 551E7A70.1030600@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2015/03/25 4:56, Tom Lane wrote:
> Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2015-04-03 11:37:49 | Re: The return value of allocate_recordbuf() |
Previous Message | Shigeru Hanada | 2015-04-03 10:32:08 | Re: Custom/Foreign-Join-APIs (Re: [v9.5] Custom Plan API) |