Thread: pgsql: Enable probes to work with Mac OS X Leopard and other OSes that

Log Message:
-----------
Enable probes to work with Mac OS X Leopard and other OSes that will
support DTrace in the future.

Switch from using DTRACE_PROBEn macros to the dynamically generated macros.
Use "dtrace -h" to create a header file that contains the dynamically
generated macros to be used in the source code instead of the DTRACE_PROBEn
macros.  A dummy header file is generated for builds without DTrace support.

Author: Robert Lor <Robert.Lor@sun.com>

Modified Files:
--------------
    pgsql/src/backend:
        Makefile (r1.127 -> r1.128)
        (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/Makefile?r1=1.127&r2=1.128)
    pgsql/src/backend/access/transam:
        xact.c (r1.259 -> r1.260)
        (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/transam/xact.c?r1=1.259&r2=1.260)
    pgsql/src/backend/storage/lmgr:
        lock.c (r1.182 -> r1.183)
        (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/storage/lmgr/lock.c?r1=1.182&r2=1.183)
        lwlock.c (r1.50 -> r1.51)
        (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/storage/lmgr/lwlock.c?r1=1.50&r2=1.51)
    pgsql/src/backend/utils:
        Makefile (r1.26 -> r1.27)
        (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/Makefile?r1=1.26&r2=1.27)
    pgsql/src/include:
        Makefile (r1.23 -> r1.24)
        (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/Makefile?r1=1.23&r2=1.24)
        c.h (r1.223 -> r1.224)
        (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/c.h?r1=1.223&r2=1.224)
        pg_trace.h (r1.3 -> r1.4)
        (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/pg_trace.h?r1=1.3&r2=1.4)

Added Files:
-----------
    pgsql/src/backend/utils:
        Gen_dummy_probes.sed (r1.1)

(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/Gen_dummy_probes.sed?rev=1.1&content-type=text/x-cvsweb-markup)

petere@postgresql.org (Peter Eisentraut) writes:
> Switch from using DTRACE_PROBEn macros to the dynamically generated macros.
> Use "dtrace -h" to create a header file that contains the dynamically
> generated macros to be used in the source code instead of the DTRACE_PROBEn
> macros.  A dummy header file is generated for builds without DTrace support.

Gen_dummy_probes.sed?  How likely is that to work on Windows?

            regards, tom lane

Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane wrote:
>> Gen_dummy_probes.sed?  How likely is that to work on Windows?

> I think if they can run Gen_fmgrtab, they can get this to work.

They can't.

            regards, tom lane

Tom Lane wrote:
> petere@postgresql.org (Peter Eisentraut) writes:
> > Switch from using DTRACE_PROBEn macros to the dynamically generated
> > macros. Use "dtrace -h" to create a header file that contains the
> > dynamically generated macros to be used in the source code instead of the
> > DTRACE_PROBEn macros.  A dummy header file is generated for builds
> > without DTrace support.
>
> Gen_dummy_probes.sed?  How likely is that to work on Windows?

I think if they can run Gen_fmgrtab, they can get this to work.

Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane wrote:
>> Peter Eisentraut <peter_e@gmx.net> writes:
>>> I think if they can run Gen_fmgrtab, they can get this to work.
>>
>> They can't.

> They can't run Gen_fmgrtab or they can't get this to work?

They can't run Gen_fmgrtab.  The MSVC port has its own reimplementation
of that script, and I suppose now it's going to need one to substitute
for this, too.

            regards, tom lane

Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
> > Tom Lane wrote:
> >> Gen_dummy_probes.sed?  How likely is that to work on Windows?
> >
> > I think if they can run Gen_fmgrtab, they can get this to work.
>
> They can't.

They can't run Gen_fmgrtab or they can't get this to work?

Peter Eisentraut wrote:
> Modified Files:
> --------------
>     pgsql/src/backend:
>         Makefile (r1.127 -> r1.128)
>         (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/Makefile?r1=1.127&r2=1.128)
>     pgsql/src/backend/access/transam:
>         xact.c (r1.259 -> r1.260)
>         (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/transam/xact.c?r1=1.259&r2=1.260)
>     pgsql/src/backend/storage/lmgr:
>         lock.c (r1.182 -> r1.183)
>         (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/storage/lmgr/lock.c?r1=1.182&r2=1.183)
>         lwlock.c (r1.50 -> r1.51)
>         (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/storage/lmgr/lwlock.c?r1=1.50&r2=1.51)
>     pgsql/src/backend/utils:
>         Makefile (r1.26 -> r1.27)
>         (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/Makefile?r1=1.26&r2=1.27)
>     pgsql/src/include:
>         Makefile (r1.23 -> r1.24)
>         (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/Makefile?r1=1.23&r2=1.24)
>         c.h (r1.223 -> r1.224)
>         (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/c.h?r1=1.223&r2=1.224)
>         pg_trace.h (r1.3 -> r1.4)
>         (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/pg_trace.h?r1=1.3&r2=1.4)
>
> Added Files:
> -----------
>     pgsql/src/backend/utils:
>         Gen_dummy_probes.sed (r1.1)
>
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/Gen_dummy_probes.sed?rev=1.1&content-type=text/x-cvsweb-markup)
>
>
You didn't include the changes in pgsql/src/Makefile.  By generating
probes.h before the compile starts, it will allow probes to be added
outside the backend without having to do anything extra. Is this not the
right way or you think it's not needed now?

Regards,
-Robert

Robert Lor wrote:
> You didn't include the changes in pgsql/src/Makefile.  By generating
> probes.h before the compile starts, it will allow probes to be added
> outside the backend without having to do anything extra. Is this not the
> right way or you think it's not needed now?

Once we have that situation, we can think about the right way to implement it.
Worst case, we just put the hunk back.  But it is not needed now.