PostgreSQL DTrace Users Guide 1. Overview 2. Compile - PgFoundry

disturbedoctopusGestion des données

27 nov. 2012 (il y a 6 années et 1 mois)

415 vue(s)

PostgreSQL DTrace Users Guide
Robert Lor (
Last updated: 8/8/06
1. Overview
PostgreSQL 8.2 now has a number of DTrace probes embedded in the source code. These probes will

enable developers and system administrators to easily observe the behavior of PostgreSQL with simple

scripting programs called D scripts. The current set of probes is fairly small, but more can easily be

added, and the community is encouraged to contribute more. The probes were added using the Generic

Monitoring Framework. See this proposal for more details
This document describes how to:

Compile PostgreSQL with DTrace

Use the existing DTrace probes

Add new DTrace probes
2. Compile PostgreSQL with DTrace
By default DTrace probes are disabled, and the user needs to explicitly tell the configure script to make

the probes available in PostgreSQL. Certainly, enabling DTrace only makes sense on Operating Systems

with DTrace facility. Currently DTrace is available on Solaris 10+ and soon on FreeBSD and Mac OS X.
To include DTrace probes in a 32 bit binary, specify --enable-dtrace to configure. For example:
$ configure --enable-dtrace ...
To include DTrace probes in a 64 bit binary, specify --enable-dtrace and DTRACEFLAGS="-64" to

configure. For example:
$ configure CC='gcc -m64' --enable-dtrace DTRACEFLAGS='-64' ...
a) To successfully compile PostgreSQL 8.2 with --enable-dtrace, you need to run Solaris Express

available at The DTrace version in Solaris

10 (up until 6/06) does not allow probes to be added to static functions. This limitation will be fixed in

future updates of Solaris 10.
b) When using DTRACEFLAGS='-64', you also have to specify -m64 (for 64-bit binary in gcc) to

configure; otherwise, you will get compilation errors.
3. Use Existing DTrace Probes
Using the probes in PostgreSQL is similar to using probes in other DTrace providers. Below is an

example of a simple D script using the transaction-start, transaction-commit, and transaction-abort

probes. The script prints out the total number of started, committed, and aborted transactions.
#!/usr/sbin/dtrace -qs
@start["Start"] = count();
self->ts = timestamp;
@abort["Abort"] = count();
@commit["Commit"] = count();
@time["Total time (ns)"] = sum(timestamp - self->ts);
Executing the above script produces the following output.
# ./txn_count.d `pgrep -n postgres`
Total time (ns)
A number of sample D scripts are available at
To learn more about DTrace, refer to the following HowTo and DTrace Guides.
4. Add New DTrace Probes
New DTrace probes can easily be added to PostgreSQL. For example, to add a probe called transaction-
start, follow these simple steps:
1) Add the probe definitions to src/backend/utils/probes.d
provider postgresql {
probe transaction__start(int);
When a dash (-) is used in the probe name, it needs to be converted to double underscores (__) in the

probe definition file. So, the above probe is called transaction-start in the D script.
2) Add "PG_TRACE1 (transaction__start, s->transactionId);" to backend/access/transam/xact.c
static void
* generate a new transaction id
s->transactionId = GetNewTransactionId(false);
PG_TRACE1 (transaction__start, s->transactionId);
a) PG_TRACE1 is mapped to DTRACE_PROBE1. See src/include/pg_trace.h.
b) The provider name for all probes in PostgreSQL is called postgresql per the decision by the

developers, so it's not specified in PG_TRACE. See src/include/pg_trace.h.
c) Make sure the data types in the probe definition match the argument passed to the probe. In this case s-
>transactionId has to be an integer (int).
When you have probes that might be useful to the community at large, send a proposal/patch to pgsql- to get feedback from the developers.
3) Check to make sure the new probe is available
After recompiling, run the new binary, and as root, execute the following DTrace command to check that

your newly added probe is available.
# dtrace -l -n transaction-start