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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
