<term><option>--load-via-partition-root</option></term>
      <listitem>
       <para>
        When dumping data for a table partition, make
        the <command>COPY</command> or <command>INSERT</command> statements
        target the root of the partitioning hierarchy that contains it, rather
        than the partition itself.  This causes the appropriate partition to
        be re-determined for each row when the data is loaded.  This may be
        useful when restoring data on a server where rows do not always fall
        into the same partitions as they did on the original server.  That
        could happen, for example, if the partitioning column is of type text
        and the two systems have different definitions of the collation used
        to sort the partitioning column.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><option>--lock-wait-timeout=<replaceable class="parameter">timeout</replaceable></option></term>
      <listitem>
       <para>
        Do not wait forever to acquire shared table locks at the beginning of
        the dump. Instead fail if unable to lock a table within the specified
        <replaceable class="parameter">timeout</replaceable>. The timeout may be
        specified in any of the formats accepted by <command>SET
        statement_timeout</command>.  (Allowed formats vary depending on the server
        version you are dumping from, but an integer number of milliseconds
        is accepted by all versions.)
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><option>--no-comments</option></term>
      <listitem>
       <para>
        Do not dump <command>COMMENT</command> commands.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><option>--no-data</option></term>
      <listitem>
       <para>
        Do not dump data.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><option>--no-policies</option></term>
      <listitem>
       <para>
        Do not dump row security policies.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><option>--no-publications</option></term>
      <listitem>
       <para>
        Do not dump publications.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><option>--no-schema</option></term>
      <listitem>
       <para>
        Do not dump schema (data definitions).
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><option>--no-security-labels</option></term>
      <listitem>
       <para>
        Do not dump security labels.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><option>--no-statistics</option></term>
      <listitem>
       <para>
        Do not dump statistics. This is the default.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><option>--no-subscriptions</option></term>
      <listitem>
       <para>
        Do not dump subscriptions.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><option>--no-sync</option></term>
      <listitem>
       <para>
        By default, <command>pg_dump</command> will wait for all files
        to be written safely to disk.  This option causes
        <command>pg_dump</command> to return without waiting, which is
        faster, but means that a subsequent operating system crash can leave
        the dump corrupt.  Generally, this option is useful for testing
        but should not be used when dumping data from production installation.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><option>--no-table-access-method</option></term>
      <listitem>
       <para>
        Do not output commands to select table access methods.
        With this option, all objects will be created with whichever
        table access