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

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

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:

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:

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 <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:

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.

Well, yes. I meant to say, a build system that can supply the functionality
of Gen_fmgrtab can surely implement this new thing. I see there is Perl
being used, so it should be simple.

On Mon, Mar 17, 2008 at 7:44 PM, Peter Eisentraut <petere@postgresql.org> wrote:

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.

Do we need some support in the buildfarm to create the header file?

--
Dave Page
EnterpriseDB UK Ltd: http://www.enterprisedb.com
PostgreSQL UK 2008 Conference: http://www.postgresql.org.uk

Am Dienstag, 18. M�rz 2008 schrieb Dave Page:

On Mon, Mar 17, 2008 at 7:44 PM, Peter Eisentraut <petere@postgresql.org>

wrote:

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.

Do we need some support in the buildfarm to create the header file?

The Windows/MSVC build system needs some adjustments. I have no idea how it
works, but I'd be glad to explain the details to someone who does.

On Tue, Mar 18, 2008 at 9:40 AM, Peter Eisentraut <peter_e@gmx.net> wrote:

Do we need some support in the buildfarm to create the header file?

The Windows/MSVC build system needs some adjustments. I have no idea how it
works, but I'd be glad to explain the details to someone who does.

I was actually thinking of the OS X buildfarm member I setup to
exercise this. From your description it sounded like we need to
generate the probe header manually if we enable dtrace.

I'm sure Magnus would love to hear the details for the MSVC perl scipts :-p

--
Dave Page
EnterpriseDB UK Ltd: http://www.enterprisedb.com
PostgreSQL UK 2008 Conference: http://www.postgresql.org.uk

Am Dienstag, 18. M�rz 2008 schrieb Dave Page:

I was actually thinking of the OS X buildfarm member I setup to
exercise this. From your description it sounded like we need to
generate the probe header manually if we enable dtrace.

Nope.

On Tue, Mar 18, 2008 at 11:48 AM, Peter Eisentraut <peter_e@gmx.net> wrote:

Am Dienstag, 18. März 2008 schrieb Dave Page:

I was actually thinking of the OS X buildfarm member I setup to
exercise this. From your description it sounded like we need to
generate the probe header manually if we enable dtrace.

Nope.

OK, I'll enable it on antelope then.

Shouldn't there have been a doc patch with this as well? Last time I
read the docs they said only Solaris supports dtrace.

--
Dave Page
EnterpriseDB UK Ltd: http://www.enterprisedb.com
PostgreSQL UK 2008 Conference: http://www.postgresql.org.uk

Dave Page wrote:

Shouldn't there have been a doc patch with this as well? Last time I
read the docs they said only Solaris supports dtrace.

Well, it won't support anything else until somebody tries debugs it ;-)

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

Alvaro Herrera <alvherre@commandprompt.com> writes:

Dave Page wrote:

Shouldn't there have been a doc patch with this as well? Last time I
read the docs they said only Solaris supports dtrace.

Well, it won't support anything else until somebody tries debugs it ;-)

Well, I've got Leopard here, I'd be happy to test it ... but the patch
has rendered
http://developer.postgresql.org/pgdocs/postgres/dynamic-trace.html
into a pack of lies quite independently of which OSes are supported,
so I'm not very sure what to do.

regards, tom lane

Am Dienstag, 18. M�rz 2008 schrieb Tom Lane:

Well, I've got Leopard here, I'd be happy to test it ... but the patch
has rendered
http://developer.postgresql.org/pgdocs/postgres/dynamic-trace.html
into a pack of lies quite independently of which OSes are supported,
so I'm not very sure what to do.

Ah yes. Robert, do you think you could update the documentation a bit on how
to use the tracing?

Peter Eisentraut wrote:

Well, yes. I meant to say, a build system that can supply the functionality
of Gen_fmgrtab can surely implement this new thing. I see there is Perl
being used, so it should be simple.

I was thinking of using a Perl script to generate the dummy header file
but decided against it to avoid disrupting the build on other platforms.
If sed doesn't work on Windows for some reason, we can use a Perl script
instead.

Regards,
-Robert

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&amp;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&amp;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&amp;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&amp;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&amp;r2=1.27)
pgsql/src/include:
Makefile (r1.23 -> r1.24)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/Makefile?r1=1.23&amp;r2=1.24)
c.h (r1.223 -> r1.224)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/c.h?r1=1.223&amp;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&amp;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&amp;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

Peter Eisentraut wrote:

Am Dienstag, 18. M�rz 2008 schrieb Tom Lane:

Well, I've got Leopard here, I'd be happy to test it ... but the patch
has rendered
http://developer.postgresql.org/pgdocs/postgres/dynamic-trace.html
into a pack of lies quite independently of which OSes are supported,
so I'm not very sure what to do.

Ah yes. Robert, do you think you could update the documentation a bit on how
to use the tracing?

Yes, the doc needs to be updated. Will submit a patch soon!

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.

Robert Lor wrote:

Peter Eisentraut wrote:

Well, yes. I meant to say, a build system that can supply the
functionality of Gen_fmgrtab can surely implement this new thing. I
see there is Perl being used, so it should be simple.

I was thinking of using a Perl script to generate the dummy header
file but decided against it to avoid disrupting the build on other
platforms. If sed doesn't work on Windows for some reason, we can use
a Perl script instead.

Perl is required for all MSVC builds, and for all builds from CVS on any
platform too, IIRC, so it's a fairly safe bet for any tool you provide.

cheers

andrew