Skip site navigation (1) Skip section navigation (2)

Re: Review: DTrace probes (merged version) ver_03

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM>
Cc: Robert Lor <Robert(dot)Lor(at)Sun(dot)COM>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>, jesus(at)omniti(dot)com
Subject: Re: Review: DTrace probes (merged version) ver_03
Date: 2008-07-28 14:16:21
Message-ID: 18516.1217254581@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM> writes:
> Whats about #include "c.h"? Does it work or does it have same issue?

Same problem --- postgres.h isn't actually including any of the
problematic files for itself.

>> What I suggest might be a reasonable compromise is to copy needed
>> typedefs directly into the probes.d file:

> It works on Solaris as well. However, I think that better solution is to put 
> this typedef to the separate header file.

Not going to work, at least not in the general case, because the
typedefs involved are ultimately dependent on system headers that might
or might not be DTrace-clean.  In any case I'm going to resist doing
random restructuring of our core header files for the convenience
of DTrace --- if we take that approach, adding a new probe becomes
a major PITA instead of just a couple more lines of code.  You're likely
to find requests for new probes getting rejected because the required
header rearrangements are too ugly; do you want to take that risk?

We could put the typedefs into probes.d as a stopgap measure, hoping
that Apple (and Sun?) will someday fix their headers and/or the D
compiler so that #include'ing postgres.h works properly.

			regards, tom lane

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2008-07-28 14:56:31
Subject: Re: WITH RECUSIVE patches 0723
Previous:From: Zdenek KotalaDate: 2008-07-28 14:13:11
Subject: Re: Review: DTrace probes (merged version) ver_03

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group