found by the deadlock
      detector.</entry>
    </row>

   </tbody>
   </tgroup>
  </table>

 <table id="typedefs-table">
  <title>Defined Types Used in Probe Parameters</title>
  <tgroup cols="2">
   <thead>
    <row>
     <entry>Type</entry>
     <entry>Definition</entry>
    </row>
   </thead>

   <tbody>

    <row>
     <entry><type>LocalTransactionId</type></entry>
     <entry><type>unsigned int</type></entry>
    </row>
    <row>
     <entry><type>LWLockMode</type></entry>
     <entry><type>int</type></entry>
    </row>
    <row>
     <entry><type>LOCKMODE</type></entry>
     <entry><type>int</type></entry>
    </row>
    <row>
     <entry><type>BlockNumber</type></entry>
     <entry><type>unsigned int</type></entry>
    </row>
    <row>
     <entry><type>Oid</type></entry>
     <entry><type>unsigned int</type></entry>
    </row>
    <row>
     <entry><type>ForkNumber</type></entry>
     <entry><type>int</type></entry>
    </row>
    <row>
     <entry><type>bool</type></entry>
     <entry><type>unsigned char</type></entry>
    </row>

   </tbody>
   </tgroup>
  </table>


  </sect2>

  <sect2 id="using-trace-points">
   <title>Using Probes</title>

  <para>
   The example below shows a DTrace script for analyzing transaction
   counts in the system, as an alternative to snapshotting
   <structname>pg_stat_database</structname> before and after a performance test:
<programlisting>
#!/usr/sbin/dtrace -qs

postgresql$1:::transaction-start
{
      @start["Start"] = count();
      self->ts  = timestamp;
}

postgresql$1:::transaction-abort
{
      @abort["Abort"] = count();
}

postgresql$1:::transaction-commit
/self->ts/
{
      @commit["Commit"] = count();
      @time["Total time (ns)"] = sum(timestamp - self->ts);
      self->ts=0;
}
</programlisting>
   When executed, the example D script gives output such as:
<screen>
# ./txn_count.d `pgrep -n postgres` or ./txn_count.d &lt;PID&gt;
^C

Start                                          71
Commit                                         70
Total time (ns)                        2312105013
</screen>
  </para>

  <note>
   <para>
    SystemTap uses a different notation for trace scripts than DTrace does,
    even though the underlying trace points are compatible.  One point worth
    noting is that at this writing, SystemTap scripts must reference probe
    names using double underscores in place of hyphens.  This is expected to
    be fixed in future SystemTap releases.
   </para>
  </note>

  <para>
   You should remember that DTrace scripts need to be carefully written and
   debugged, otherwise the trace information collected might
   be meaningless. In most cases where problems are found it is the
   instrumentation that is at fault, not the underlying system. When
   discussing information found using dynamic tracing, be sure to enclose
   the script used to allow that too to be checked and discussed.
  </para>
  </sect2>

  <sect2 id="defining-trace-points">
   <title>Defining New Probes</title>

  <para>
   New probes can be defined within the code wherever the developer
   desires, though this will require a recompilation. Below are the steps
   for inserting new probes:
  </para>

  <procedure>
   <step>
    <para>
     Decide on probe names and data to be made available through the probes
    </para>
   </step>

   <step>
    <para>
     Add the probe definitions to <filename>src/backend/utils/probes.d</filename>
    </para>
   </step>

   <step>
    <para>
     Include <filename>pg_trace.h</filename> if it is not already present in the
     module(s) containing the probe points, and insert
     <literal>TRACE_POSTGRESQL</literal> probe macros at the desired locations
     in the source code
    </para>
   </step>

   <step>
    <para>
     Recompile and verify that the new probes are available
    </para>
   </step>
  </procedure>

  <formalpara>
   <title>Example:</title>
   <para>
    Here is an example of how you would add a probe to trace all new
    transactions