Re: DTrace probe patch for OS X Leopard

From: Robert Lor <Robert(dot)Lor(at)Sun(dot)COM>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-patches(at)postgresql(dot)org
Subject: Re: DTrace probe patch for OS X Leopard
Date: 2008-02-29 17:11:14
Message-ID: 47C83CB2.7040306@sun.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

Tom Lane wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
>
>> Hmm, so let's have a third file that's not autogenerated, which is the
>> file we will use for #includes, and contains just that block.
>>
>
> Or just two files. Call probes_null something else, have it be included
> where needed, have it include the autogenerated file when appropriate.
>
>

I really like this idea. So, we're now back to having pg_trace.h which
includes the autogenerated probes.h when Dtrace is enabled, else null
macros will be used.

Currently, pg_trace.h is included in c.h, and I feel strongly that it
should remains there because by design I'd like to
1) have the tracing feature be available both in the frontend and
backend without having to do anything extra, which also means that
probes.h needs to be generated before any compilation
2) centralize the include of this header just in case the
implementation needs to be changed for some reason (eg, if this file
needs to be splitted, etc)
3) reduce the number of changes to a minimal when adding new probes to
new .c files

I haven't heard any major disadvantages about keeping it in c.h, but if
you are still adamant about keeping it out of c.h, I'll will go along
with that.

Regards,
-Robert

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2008-02-29 17:55:57 Re: DTrace probe patch for OS X Leopard
Previous Message Tom Lane 2008-02-29 16:03:13 Re: DTrace probe patch for OS X Leopard