Re: EvalPlanQual behaves oddly for FDW queries involving system columns

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-04-03 11:45:28
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 2015/03/13 0:50, Tom Lane wrote:
> I think the real fix as far as postgres_fdw is concerned is in fact
> to let it adopt a different ROW_MARK strategy, since it has meaningful
> ctid values. However, that is not a one-size-fits-all answer.

> 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.

To support ROW_MARK_REFERENCE on (postgres_fdw) foreign tables, I'd like
to propose the following FDW APIs:

GetForeignRowMarkType(Oid relid,
LockClauseStrength strength);

Decide which rowmark type to use for a foreign table (that has strength
second argument takes LCS_NONE only, but is intended to be used for the
possible extension to the other cases.) This is called during
select_rowmark_type() in the planner.

BeginForeignFetch(EState *estate,
ExecRowMark *erm,
List *fdw_private,
int eflags);

Begin a remote fetch. This is called during InitPlan() in the executor.

ExecForeignFetch(EState *estate,
ExecRowMark *erm,
ItemPointer tupleid);

Re-fetch the specified tuple. This is called during
EvalPlanQualFetchRowMarks() in the executor.

EndForeignFetch(EState *estate,
ExecRowMark *erm);

End a remote fetch. This is called during ExecEndPlan() in the executor.

And I'd also like to propose to add a table/server option,
row_mark_reference, to postgres_fdw. When a user sets the option to
true for eg a foreign table, ROW_MARK_REFERENCE will be used for the
table, not ROW_MARK_COPY.

Attached is a WIP patch, which contains no docs/regression tests.

It'd be appreciated if anyone could send back any comments earlier.

Best regards,
Etsuro Fujita

Attachment Content-Type Size
EvalPlanQual-v3.patch text/x-patch 34.9 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2015-04-03 12:07:04 Re: Re: Abbreviated keys for Datum tuplesort
Previous Message Jan Urbański 2015-04-03 11:44:31 Re: libpq's multi-threaded SSL callback handling is busted