mirror/postgresql
2
0
Fork 0
mirror of https://git.postgresql.org/git/postgresql.git synced 2024-12-27 08:39:28 +08:00
Code Issues Packages Projects Releases Wiki Activity

Collect the bits of wisdom about dtrace installation in the installation

Browse Source 
chapter rather than scattering them across several incomplete fragments.

(This makes the documentation consistent with the backported FAQ_Solaris.)
This commit is contained in:
Peter Eisentraut 2006-12-12 16:07:42 +00:00
parent d94fa4183f
commit 9178874f34
2 changed files with 25 additions and 28 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

15
doc/src/sgml/installation.sgml
View File

@ -1,4 +1,4 @@
<!-- $PostgreSQL: pgsql/doc/src/sgml/installation.sgml,v 1.267 2006/12/01 21:17:51 tgl Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/installation.sgml,v 1.267.2.1 2006/12/12 16:07:41 petere Exp $ -->
<chapter id="installation">
<title><![%standalone-include[<productname>PostgreSQL</>]]>
@ -1039,6 +1039,19 @@ su - postgres
specified in the environment variable
<envar>DTRACEFLAGS</envar>.
</para>
<para>
To include DTrace support in a 64-bit binary, specify
<literal>DTRACEFLAGS="-64"</> to configure. For example,
using the GCC compiler:
<screen>
./configure CC='gcc -m64' --enable-dtrace DTRACEFLAGS='-64' ...
</screen>
Using Sun's compiler:
<screen>
./configure CC='/opt/SUNWspro/bin/cc -xtarget=native64' --enable-dtrace DTRACEFLAGS='-64' ...
</screen>
</para>
</listitem>
</varlistentry>

38
doc/src/sgml/monitoring.sgml
View File

@ -1,4 +1,4 @@
<!-- $PostgreSQL: pgsql/doc/src/sgml/monitoring.sgml,v 1.40 2006/12/02 00:42:54 tgl Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/monitoring.sgml,v 1.40.2.1 2006/12/12 16:07:42 petere Exp $ -->
<chapter id="monitoring">
<title>Monitoring Database Activity</title>
@ -824,29 +824,14 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS procpid,
</para>
<sect2 id="compiling-for-trace">
<title>Compiling for Dynamic Trace</title>
<title>Compiling for Dynamic Tracing</title>
<para>
By default, trace points are disabled, so you will need to
explicitly tell the configure script to make the probes available
in <productname>PostgreSQL</productname>. To include DTrace support
in a 32-bit binary, specify <option>--enable-dtrace</> to configure.
For example:
<programlisting>
$ ./configure --enable-dtrace ...
</programlisting>
To include DTrace support in a 64-bit binary, specify
<option>--enable-dtrace</>
and <literal>DTRACEFLAGS="-64"</> to configure. For example,
using the gcc compiler:
<programlisting>
$ ./configure CC='gcc -m64' --enable-dtrace DTRACEFLAGS='-64' ...
</programlisting>
Using Sun's compiler:
<programlisting>
$ ./configure CC='/path_to_sun_compiler/cc -xtarget=native64' --enable-dtrace DTRACEFLAGS='-64' ...
</programlisting>
</para>
specify <option>--enable-dtrace</> to configure. See <xref
linkend="install-procedure"> for further information.
</sect2>
<sect2 id="trace-points">
@ -855,7 +840,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS procpid,
<para>
A few standard trace points are provided in the source code
(of course, more can be added as needed for a particular problem).
These are:
These are shown in <xref linkend="trace-point-table">.
</para>
<table id="trace-point-table">
@ -974,15 +959,14 @@ postgresql$1:::transaction-commit
Note how the double underline in trace point names needs to
be replaced by a hyphen when using D script.
When executed, the example D script gives output such as:
<programlisting>
<screen>
# ./txn_count.d `pgrep -n postgres`
^C
Start 71
Commit 70
Abort 1
Total time (ns) 2312105013
</programlisting>
</screen>
</para>
<para>
You should remember that trace programs need to be carefully written and
@ -999,7 +983,7 @@ Total time (ns) 2312105013
<para>
New trace points can be defined within the code wherever the developer
desires, though this will require a re-compile.
desires, though this will require a recompilation.
</para>
<para>
@ -1009,14 +993,14 @@ Total time (ns) 2312105013
occurrence of an event can be achieved with a single line, using
just the trace point name, e.g.
<programlisting>
PG_TRACE (my__new__trace__point);
PG_TRACE (my__new__trace__point);
</programlisting>
More complex trace points can be provided with one or more variables
for inspection by the dynamic tracing utility by using the
<literal>PG_TRACE</><replaceable>n</> macro that corresponds to the number
of parameters after the trace point name:
<programlisting>
PG_TRACE3 (my__complex__event, varX, varY, varZ);
PG_TRACE3 (my__complex__event, varX, varY, varZ);
</programlisting>
The definition of the transaction__start trace point is shown below:
<programlisting>
@ -1055,7 +1039,7 @@ provider postgresql {
</para>
<para>
You should take care that the datatypes specified for the probe arguments
You should take care that the data types specified for the probe arguments
match the datatypes of the variables used in the <literal>PG_TRACE</>
macro. This is not checked at compile time. You can check that your newly
added trace point is available by recompiling, then running the new binary,