Home • Explore • Blog • CI
☰



postgresql
31th chunk of `doc/src/sgml/ref/pgbench.sgml`
2e62528d38bfaf9cd097fcab2a16b91e70b217f8b056c6350000000100000fa4
    </listitem>
    </varlistentry>

    <varlistentry>
     <term><replaceable>time_epoch</replaceable></term>
     <listitem>
      <para>
       transaction's completion time, as a Unix-epoch time stamp
      </para>
     </listitem>
    </varlistentry>

    <varlistentry>
     <term><replaceable>time_us</replaceable></term>
     <listitem>
      <para>
       fractional-second part of transaction's completion time, in
       microseconds
      </para>
     </listitem>
    </varlistentry>

    <varlistentry>
     <term><replaceable>schedule_lag</replaceable></term>
     <listitem>
      <para>
       transaction start delay, that is the difference between the
       transaction's scheduled start time and the time it actually
       started, in microseconds
       (present only if <option>--rate</option> is specified)
      </para>
     </listitem>
    </varlistentry>

    <varlistentry>
     <term><replaceable>retries</replaceable></term>
     <listitem>
      <para>
       count of retries after serialization or deadlock errors during the
       transaction
       (present only if <option>--max-tries</option> is not equal to one)
      </para>
     </listitem>
    </varlistentry>
   </variablelist>
  </para>

  <para>
   When both <option>--rate</option> and <option>--latency-limit</option> are used,
   the <replaceable>time</replaceable> for a skipped transaction will be reported as
   <literal>skipped</literal>.
   If the transaction ends with a failure, its <replaceable>time</replaceable>
   will be reported as <literal>failed</literal>. If you use the
   <option>--failures-detailed</option> option, the
   <replaceable>time</replaceable> of the failed transaction will be reported as
   <literal>serialization</literal> or
   <literal>deadlock</literal> depending on the type of failure (see
   <xref linkend="failures-and-retries"/> for more information).
  </para>

  <para>
   Here is a snippet of a log file generated in a single-client run:
<screen>
0 199 2241 0 1175850568 995598
0 200 2465 0 1175850568 998079
0 201 2513 0 1175850569 608
0 202 2038 0 1175850569 2663
</screen>

   Another example with <literal>--rate=100</literal>
   and <literal>--latency-limit=5</literal> (note the additional
   <replaceable>schedule_lag</replaceable> column):
<screen>
0 81 4621 0 1412881037 912698 3005
0 82 6173 0 1412881037 914578 4304
0 83 skipped 0 1412881037 914578 5217
0 83 skipped 0 1412881037 914578 5099
0 83 4722 0 1412881037 916203 3108
0 84 4142 0 1412881037 918023 2333
0 85 2465 0 1412881037 919759 740
</screen>
   In this example, transaction 82 was late, because its latency (6.173 ms) was
   over the 5 ms limit. The next two transactions were skipped, because they
   were already late before they were even started.
  </para>

  <para>
   The following example shows a snippet of a log file with failures and
   retries, with the maximum number of tries set to 10 (note the additional
   <replaceable>retries</replaceable> column):
<screen>
3 0 47423 0 1499414498 34501 3
3 1 8333 0 1499414498 42848 0
3 2 8358 0 1499414498 51219 0
4 0 72345 0 1499414498 59433 6
1 3 41718 0 1499414498 67879 4
1 4 8416 0 1499414498 76311 0
3 3 33235 0 1499414498 84469 3
0 0 failed 0 1499414498 84905 9
2 0 failed 0 1499414498 86248 9
3 4 8307 0 1499414498 92788 0
</screen>
  </para>

  <para>
   If the <option>--failures-detailed</option> option is used, the type of
   failure is reported in the <replaceable>time</replaceable> like this:
<screen>
3 0 47423 0 1499414498 34501 3
3 1 8333 0 1499414498 42848 0
3 2 8358 0 1499414498 51219 0
4 0 72345 0 1499414498 59433 6
1 3 41718 0 1499414498 67879 4
1 4 8416 0 1499414498 76311 0
3 3 33235 0 1499414498 84469 3
0 0 serialization 0 1499414498 84905 9
2 0 serialization 0 1499414498 86248 9
3 4 8307 0 1499414498 92788 0
</screen>
  </para>

  <para>
   When running a long test on hardware that can handle a lot of transactions,
   the log files can become very large.  The <option>--sampling-rate</option> option
Title: Details and Examples of pgbench Per-Transaction Logging
Summary
This section expands on the previous section about per-transaction logging in pgbench. It provides further details on the structure and meaning of each field in the log file, including the transaction's completion time (epoch and microseconds), schedule lag (when `--rate` is specified), and the number of retries. The section also presents sample log snippets, demonstrating how skipped and failed transactions are reported when `--rate` and `--latency-limit` are used, and how retry counts are included when `--max-tries` is set. Additionally, it illustrates how failure types (serialization or deadlock) are reported when the `--failures-detailed` option is enabled.