Dhanaraj M
Exploring other possiblities with D-Trace in PostgreSQL
User-level D-Trace probes in PostgreSQL is an article written by Robert Lor. This gives a good overview on how to debug/analyse PostgreSQL code using D-Trace (Community help documents). Here, I like to add some points which are not covered already.
D-Trace scripts provide some useful information including processID, thread-local variables, PC location and easy way to analyze the performance issues in terms of time estimation, count.
Building --enable-dtrace:
The user-level D-Trace probes have been integrated into PostgreSQL-8.2. They work only on Solaris Express (Solaris Nevada build 55 and above). The work-around on Solaris-10 is to remove static from the following functions: StartTransaction(), CommitTranaction(), and AbortTransaction()
Playing with probes:
View the existing probes and their details (provider, module, function, probe name)
> dtrace -l | grep postgres
Add additional arguments into the probes like start-transaction(int, int) and view them in the d-script using the following.
printf("ARG0:%d, ARG1:%d", arg0, arg1);
New probes can be declared in src/backend/utils/probes.d and they can be inserted at the required location with necessary arguments.
Tracing PostgreSQL code without D-Trace probes:
When the PostgreSQL server is started, the main process waits for the connection-request from the clients. As soon as it receives a client's connection request, the new process is forked and it takes-over the upcoming requests from that particular client. In addition to the main process + N - child/client processes, there are two active processes to write the logs.
To trace the control flow including the user-defined functions and system calls, a script can be written. For tracing at the time of making connection with clients, assign main process ID as processID here (fork_process as functionName). For tracing the query execution module, assign process ID of that particular client (pg_parse_query as functionName). Here, functionName plays an important role because the tracing will start only after the control reaches that functionName.
> dtrace -s myScript.d -p <processID>
pid$target::functionName:entry
{ self->trace = 1; }
pid$target::functionName:return
/self->trace/
{ self->trace = 0; }
pid$target:::entry,
pid$target:::return
/self->trace/
{}
The following script helps to track only user defined functions.
> dtrace -F -s myScript.d <processID>
pid$1:a.out::entry
{}
pid$1:a.out::return
{}
Posted at 04:06PM Jan 20, 2007 by dhanarajm in Sun | Comments[0]