definition of or removing a foreign server or
   a user mapping, the associated connections are closed.
   But note that if any connections are in use in the current local transaction,
   they are kept until the end of the transaction.
   Closed connections will be re-established when they are necessary
   by future queries using a foreign table.
  </para>

  <para>
   Once a connection to a foreign server has been established,
   it's by default kept until the local or corresponding remote
   session exits.  To disconnect a connection explicitly,
   <literal>keep_connections</literal> option for a foreign server
   may be disabled, or
   <function>postgres_fdw_disconnect</function> and
   <function>postgres_fdw_disconnect_all</function> functions
   may be used.  For example, these are useful to close
   connections that are no longer necessary, thereby releasing
   connections on the foreign server.
  </para>
 </sect2>

 <sect2 id="postgres-fdw-transaction-management">
  <title>Transaction Management</title>

  <para>
   During a query that references any remote tables on a foreign server,
   <filename>postgres_fdw</filename> opens a transaction on the
   remote server if one is not already open corresponding to the current
   local transaction.  The remote transaction is committed or aborted when
   the local transaction commits or aborts.  Savepoints are similarly
   managed by creating corresponding remote savepoints.
  </para>

  <para>
   The remote transaction uses <literal>SERIALIZABLE</literal>
   isolation level when the local transaction has <literal>SERIALIZABLE</literal>
   isolation level; otherwise it uses <literal>REPEATABLE READ</literal>
   isolation level.  This choice ensures that if a query performs multiple
   table scans on the remote server, it will get snapshot-consistent results
   for all the scans.  A consequence is that successive queries within a
   single transaction will see the same data from the remote server, even if
   concurrent updates are occurring on the remote server due to other
   activities.  That behavior would be expected anyway if the local
   transaction uses <literal>SERIALIZABLE</literal> or <literal>REPEATABLE READ</literal>
   isolation level, but it might be surprising for a <literal>READ
   COMMITTED</literal> local transaction.  A future
   <productname>PostgreSQL</productname> release might modify these rules.
  </para>

  <para>
   The remote transaction is opened in the same read/write mode as the local
   transaction: if the local transaction is <literal>READ ONLY</literal>,
   the remote transaction is opened in <literal>READ ONLY</literal> mode,
   otherwise it is opened in <literal>READ WRITE</literal> mode.
   (This rule is also applied to remote and local subtransactions.)
  </para>

  <para>
   The remote transaction is also opened in the same deferrable mode as the
   local transaction: if the local transaction is <literal>DEFERRABLE</literal>,
   the remote transaction is opened in <literal>DEFERRABLE</literal> mode,
   otherwise it is opened in <literal>NOT DEFERRABLE</literal> mode.
  </para>

  <para>
   Note that it is currently not supported by
   <filename>postgres_fdw</filename> to prepare the remote transaction for
   two-phase commit.
  </para>
 </sect2>

 <sect2 id="postgres-fdw-remote-query-optimization">
  <title>Remote Query Optimization</title>

  <para>
   <filename>postgres_fdw</filename> attempts to optimize remote queries to reduce
   the amount of data transferred from foreign servers.  This is done by
   sending query <literal>WHERE</literal> clauses to the remote server for
   execution, and by not retrieving table columns that are not needed for
   the current query.  To reduce the risk of misexecution of queries,
   <literal>WHERE</literal> clauses are not sent to the remote server unless they use
   only data types, operators, and functions that are built-in or belong to an
   extension that's listed in the foreign server's <literal>extensions</literal>