| 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-03-16 01:10:47 |
| Message-ID: | 55062D97.6030906@lab.ntt.co.jp |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2015/03/13 11:46, Etsuro Fujita wrote:
> BTW, what do you think about opening/locking foreign tables selected for
> update at InitPlan, which the original patch does? As I mentioned in
> [1], ISTM that ExecOpenScanRelation called from ExecInitForeignScan is
> assuming that.
> [1] http://www.postgresql.org/message-id/54BCBBF8.3020103@lab.ntt.co.jp
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. To fix it, I think we should open/lock such foreign tables at
InitPlan as the original patch does.
Best regards,
Etsuro Fujita
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Kapila | 2015-03-16 03:15:39 | Re: pg_rewind in contrib |
| Previous Message | Gavin Flower | 2015-03-16 00:14:10 | Re: Allow "snapshot too old" error, to prevent bloat |