an <literal>IsForeignScanParallelSafe</literal> API that indicates otherwise.
      </para>
    </listitem>

    <listitem>
      <para>
        Plan nodes that reference a correlated <literal>SubPlan</literal>.
      </para>
    </listitem>
  </itemizedlist>

 <sect2 id="parallel-labeling">
  <title>Parallel Labeling for Functions and Aggregates</title>

  <para>
    The planner cannot automatically determine whether a user-defined
    function or aggregate is parallel safe, parallel restricted, or parallel
    unsafe, because this would require predicting every operation that the
    function could possibly perform.  In general, this is equivalent to the
    Halting Problem and therefore impossible.  Even for simple functions
    where it could conceivably be done, we do not try, since this would be expensive
    and error-prone.  Instead, all user-defined functions are assumed to
    be parallel unsafe unless otherwise marked.  When using
    <xref linkend="sql-createfunction"/> or
    <xref linkend="sql-alterfunction"/>, markings can be set by specifying
    <literal>PARALLEL SAFE</literal>, <literal>PARALLEL RESTRICTED</literal>, or
    <literal>PARALLEL UNSAFE</literal> as appropriate.  When using
    <xref linkend="sql-createaggregate"/>, the
    <literal>PARALLEL</literal> option can be specified with <literal>SAFE</literal>,
    <literal>RESTRICTED</literal>, or <literal>UNSAFE</literal> as the corresponding value.
  </para>

  <para>
    Functions and aggregates must be marked <literal>PARALLEL UNSAFE</literal>
    if they write to the database, change the transaction state (other than by
    using a subtransaction for error recovery), access sequences, or make
    persistent changes to
    settings.  Similarly, functions must be marked <literal>PARALLEL
    RESTRICTED</literal> if they access temporary tables, client connection state,
    cursors, prepared statements, or miscellaneous backend-local state that
    the system cannot synchronize across workers.