Re: EvalPlanQual behaves oddly for FDW queries involving system columns

On 4/13/15 4:58 AM, Etsuro Fujita wrote:
> 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.

Why aren't we allowing SELECT FOR KEY SHARE?
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com