| 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-13 02:46:08 |
| Message-ID: | 55024F70.4060308@lab.ntt.co.jp |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2015/03/13 0:50, Tom Lane wrote:
> The tableoid problem can be fixed much less invasively as per the attached
> patch. I think that we should continue to assume that ctid is not
> meaningful (and hence should read as (4294967295,0)) in FDWs that use
> ROW_MARK_COPY, and press forward on fixing the locking issues for
> postgres_fdw by letting it use ROW_MARK_REFERENCE or something close to
> that. That would also cause ctid to read properly for rows from
> postgres_fdw.
OK, thanks!
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.
Best regards,
Etsuro Fujita
[1] http://www.postgresql.org/message-id/54BCBBF8.3020103@lab.ntt.co.jp
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Langote | 2015-03-13 04:37:11 | Re: Parallel Seq Scan |
| Previous Message | Stephen Frost | 2015-03-13 02:36:17 | Re: CATUPDATE confusion? |