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 552B9356.5070904@lab.ntt.co.jp
Whole thread Raw
In response to Re: EvalPlanQual behaves oddly for FDW queries involving system columns  (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>)
Responses Re: EvalPlanQual behaves oddly for FDW queries involving system columns
List pgsql-hackers
On 2015/04/10 21:40, Etsuro Fujita wrote:
> 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.

I added that function and modified docs a bit.  Please find attached an
updated version of the patch.

Best regards,
Etsuro Fujita

Attachment

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: TABLESAMPLE patch
Next
From: Heikki Linnakangas
Date:
Subject: Re: pg_rewind in contrib