Re: EvalPlanQual behaves oddly for FDW queries involving system columns

Поиск
Список
Период
Сортировка
От Etsuro Fujita
Тема Re: EvalPlanQual behaves oddly for FDW queries involving system columns
Дата
Msg-id 55024F70.4060308@lab.ntt.co.jp
обсуждение исходный текст
Ответ на Re: EvalPlanQual behaves oddly for FDW queries involving system columns  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: EvalPlanQual behaves oddly for FDW queries involving system columns  (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>)
Список 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 по дате отправления:

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: CATUPDATE confusion?
Следующее
От: Amit Langote
Дата:
Сообщение: Re: Parallel Seq Scan