internal <application>pgbench</application> errors (which are
               supposed to never occur...).
             </para>
           </listitem>
         </itemizedlist></para>
     </listitem>
     <listitem>
       <para>
         Errors when the thread manages its clients (e.g. the client could not
         start a connection to the database server / the socket for connecting
         the client to the database server has become invalid). In such cases
         all clients of this thread stop while other threads continue to work.
         However, <option>--exit-on-abort</option> is specified, all of the
         threads stop immediately in this case.
       </para>
     </listitem>
     <listitem>
       <para>
         Direct client errors. They lead to immediate exit from
         <application>pgbench</application> with the corresponding error message
         in the case of an internal <application>pgbench</application>
         error (which are supposed to never occur...) or when
         <option>--exit-on-abort</option> is specified. Otherwise in the worst
         case they only lead to the abortion of the failed client while other
         clients continue their run (but some client errors are handled without
         an abortion of the client and reported separately, see below). Later in
         this section it is assumed that the discussed errors are only the
         direct client errors and they are not internal
         <application>pgbench</application> errors.
       </para>
     </listitem>
   </itemizedlist>
  </para>

  <para>
   A client's run is aborted in case of a serious error; for example, the
   connection with the database server was lost or the end of script was reached
   without completing the last transaction. In addition, if execution of an SQL
   or meta command fails for reasons other than serialization or deadlock errors,
   the client is aborted. Otherwise, if an SQL command fails with serialization or
   deadlock errors, the client is not aborted. In such cases, the current
   transaction is rolled back, which also includes setting the client variables
   as they were before the run of this transaction (it is assumed that one
   transaction script contains only one transaction; see
   <xref linkend="transactions-and-scripts"/> for more information).
   Transactions with serialization or deadlock errors are repeated after
   rollbacks until they complete successfully or reach the maximum
   number of tries (specified by the <option>--max-tries</option> option) / the maximum
   time of retries (specified by the <option>--latency-limit</option> option) / the end
   of benchmark (specified by the <option>--time</option> option). If
   the last trial run fails, this transaction will be reported as failed but
   the client is not aborted and continues to work.
  </para>

  <note>
   <para>
    Without specifying the <option>--max-tries</option> option, a transaction will
    never be retried after a serialization or deadlock error because its default
    value is 1. Use an unlimited number of tries (<literal>--max-tries=0</literal>)
    and the <option>--latency-limit</option> option to limit only the maximum time
    of tries. You can also use the <option>--time</option> option to limit the
    benchmark duration under an unlimited number of tries.
   </para>
   <para>
    Be careful when repeating scripts that contain multiple transactions: the
    script is always retried completely, so successful transactions can be
    performed several times.
   </para>
   <para>
    Be careful when repeating transactions with shell commands. Unlike the
    results of SQL commands, the results of shell commands are not rolled back,
    except for the variable value of the <command>\setshell</command> command.
   </para>
  </note>

  <para>
   The latency of a successful transaction includes the entire time of
   transaction execution with rollbacks and retries. The latency is measured
   only