Home • Explore • Blog • CI
☰



postgresql
33th chunk of `doc/src/sgml/fdwhandler.sgml`
a04b9426f1d1dd29c53f4909b707d1b1c25d276389e50b290000000100000808
 this is
     done by including the TIDs of the non-target tables in the column list
     projected through the join, and then re-fetching non-target rows when
     required.  This approach keeps the join data set compact, but it
     requires inexpensive re-fetch capability, as well as a TID that can
     uniquely identify the row version to be re-fetched.  By default,
     therefore, the approach used with foreign tables is to include a copy of
     the entire row fetched from a foreign table in the column list projected
     through the join.  This puts no special demands on the FDW but can
     result in reduced performance of merge and hash joins.  An FDW that is
     capable of meeting the re-fetch requirements can choose to do it the
     first way.
    </para>

    <para>
     For an <command>UPDATE</command> or <command>DELETE</command> on a foreign table, it
     is recommended that the <literal>ForeignScan</literal> operation on the target
     table perform early locking on the rows that it fetches, perhaps via the
     equivalent of <command>SELECT FOR UPDATE</command>.  An FDW can detect whether
     a table is an <command>UPDATE</command>/<command>DELETE</command> target at plan time
     by comparing its relid to <literal>root-&gt;parse-&gt;resultRelation</literal>,
     or at execution time by using <function>ExecRelationIsTargetRelation()</function>.
     An alternative possibility is to perform late locking within the
     <function>ExecForeignUpdate</function> or <function>ExecForeignDelete</function>
     callback, but no special support is provided for this.
    </para>

    <para>
     For foreign tables that are specified to be locked by a <command>SELECT
     FOR UPDATE/SHARE</command> command, the <literal>ForeignScan</literal> operation can
     again perform early locking by fetching tuples with the equivalent
     of <command>SELECT FOR UPDATE/SHARE</command>.  To perform late locking
     instead, provide the callback functions defined
     in <xref linkend="fdw-callbacks-row-locking"/>.
Title: Row Locking in UPDATE/DELETE and SELECT FOR UPDATE/SHARE Operations
Summary
This section discusses row locking strategies for UPDATE/DELETE and SELECT FOR UPDATE/SHARE operations on foreign tables. It recommends that ForeignScan operations perform early locking on fetched rows, similar to SELECT FOR UPDATE, and outlines how an FDW can identify an UPDATE/DELETE target. Alternatively, late locking within ExecForeignUpdate or ExecForeignDelete callbacks is possible, though without specific support. For SELECT FOR UPDATE/SHARE, ForeignScan can again perform early locking, or late locking can be implemented using specific callback functions.