Re: EvalPlanQual behaves oddly for FDW queries involving system columns - Mailing list pgsql-hackers

From Etsuro Fujita
Subject Re: EvalPlanQual behaves oddly for FDW queries involving system columns
Date
Msg-id 55024F70.4060308@lab.ntt.co.jp
Whole thread Raw
In response to Re: EvalPlanQual behaves oddly for FDW queries involving system columns  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: EvalPlanQual behaves oddly for FDW queries involving system columns
List 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



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: CATUPDATE confusion?
Next
From: Amit Langote
Date:
Subject: Re: Parallel Seq Scan