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-10 12:40:49
Message-ID: 5527C4D1.9070808@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2015/04/09 12:07, Etsuro Fujita wrote:
> I'll update the patch, which will contain only an infrastructure for
> this in the PG core, and will not contain any postgres_fdw change.

I updated the patch based on your comments. Updated patch attached. In
the patch the following FDW APIs have been proposed:

+ RowMarkType
+ GetForeignRowMarkType (LockClauseStrength strength);

+ bool
+ LockForeignRow (EState *estate,
+ ExecRowMark *erm,
+ ItemPointer tupleid);

+ HeapTuple
+ FetchForeignRow (EState *estate,
+ ExecRowMark *erm,
+ ItemPointer tupleid);

I think that these APIs allow the FDW that has TIDs to use the rowmark
options such as ROW_MARK_REFERENCE, ROW_MARK_SHARE and
ROW_MARK_EXCLUSIVE for its foreign tables so as to match the local
semantics exactly, for example.

As you mentioned, it would be better to add helper functions to see
whether the foreign table is referenced by any ExecRowMarks. ISTM that
an easy way to do that is to modify ExecFindRowMark() so that it allows
for the missing case. I didn't contain such functions in the patch, though.

Best regards,
Etsuro Fujita

Attachment Content-Type Size
EvalPlanQual-v4.patch text/x-diff 14.1 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2015-04-10 13:01:45 Re: pg_rewind tests
Previous Message Michael Paquier 2015-04-10 12:14:37 Re: SSL information view