From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> |
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-03-24 19:56:27 |
Message-ID: | 5331.1427226987@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2015-03-24 20:04:18 | Re: logical column ordering |
Previous Message | Bruce Momjian | 2015-03-24 19:52:26 | Re: printing table in asciidoc with psql |