Attached is the doc patch for the recent DTrace changes
http://archives.postgresql.org/pgsql-committers/2008-03/msg00316.php
Regards,
-Robert
Index: doc/src/sgml/installation.sgml
===
RCS file: /projects/cvsroot/pgsql/doc/src/sgml/in
Hi Peter,
Robert Lor wrote:
Attached is the updated patch which addressed all the concerns from
Peter and Tom.
I believe you're the reviewer of this patch. Any idea when it will be
applied? As far as I'm concerned, all the issues that were raised have
been addressed in the la
Attached is the updated patch which addressed all the concerns from
Peter and Tom.
* The header file containing the probe macros is now included only in
the .c files that need it.
* All probe macro names now start with TRACE_ (eg:
TRACE_POSTGRESQL_TRANSACTION_START).
Regards,
-Robert
Index
Alvaro Herrera wrote:
Would it work to name the traces "trace_transaction__start" etc instead?
AFAICS that would cause the macros to be named
POSTGRESQL_TRACE_TRANSACTION_START()
Correct, and that would work. With this approach, all the probe names
will start with trace-, and this particular
Peter Eisentraut wrote:
I think each component would have its own probes definition file.
A while back when we met in Toronto, the consensus was to only have one
provider called "postgresql" and all probes whether they be from the
backend or frontend will be grouped together in this one pr
Peter Eisentraut wrote:
I had already solved this in my intermediate patch I sent you by symlinking
probes_null.h to probes.h.
Now I see why you created the symlink. But I thinkt the suggestion by
Tom/Avaro to include probes.h and the content of probes_null.h in a
separate header (pg_tra
Tom Lane wrote:
We still have what I consider a big problem with the names of the
macros. Perhaps that could be fixed by passing the auto-generated
file through a sed script to put a prefix on the macro names before
we start to use it?
Post processing the auto generated header may work, but
Tom Lane wrote:
Alvaro Herrera <[EMAIL PROTECTED]> 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
Alvaro Herrera wrote:
Robert Lor wrote:
My concern is that when we start adding more probes (not just the
backend), we will have to add the following 5 lines in .c files that use
the Dtrace macros. This seems intrusive and messy to me instead of in a
centralized place like c.h. What
Peter Eisentraut wrote:
Another thing that is concerning me about this new approach is the way the
probes are named. For example, we'd now have a call
POSTGRESQL_LWLOCK_ACQUIRE()
in the code. This does not say we are *tracing* lock aquisition, but it looks
like a macro that actually acquire
Tom Lane wrote:
I agree with Peter. There are a whole lot of include files that are
needed by way more than 3 .c files, and yet are not folded into
postgres.h. c.h is right out.
My concern is that when we start adding more probes (not just the
backend), we will have to add the following 5 l
Peter Eisentraut wrote:
Is c.h the right place to include this? The probes are only in the backend
code, so perhaps postgres.h would be more appropriate. Or just include it in
the .c files that need it, of which there are only 3.
I think putting probes.h in c.h is the right place. It's true
Peter,
Robert Lor wrote:
Peter Eisentraut wrote:
I have reworked your build rules so they look more like the idioms
that we already use for other similar cases. This should fix the
troubles you describe and others.
There are a couple of problems with your updated patch:
Based on your
Peter Eisentraut wrote:
I have reworked your build rules so they look more like the idioms that we
already use for other similar cases. This should fix the troubles you
describe and others.
There are a couple of problems with your updated patch:
1) utils/probes.h needs to be generated befo
Peter Eisentraut wrote:
Robert Lor wrote:
Please find the patch attached per this thread
http://archives.postgresql.org/pgsql-hackers/2008-02/msg00912.php
Why do we have two dtrace calls in the makefiles now?
The build process for Mac OS X is different than that of Solaris. The
Alvaro Herrera wrote:
Perhaps you need a $< there:
$(DTRACE) $(DTRACEFLAGS) -G -s $< $(call expand_subsys,$^) -o $@
However I think you would also need to $(filter-out) the $< from $^.
Your suggestion with $(filter-out ...) works. Thanks!
Attached is the updated patch.
Regards,
-R
Please find the patch attached per this thread
http://archives.postgresql.org/pgsql-hackers/2008-02/msg00912.php
Notes to committer.
1) Please remove src/include/pg_trace.h as it's no longer needed
2) Need help figuring out how to copy src/backend/util/probes.d from src
tree to
bld tree at bu
Simon Riggs wrote On 12/02/06 06:50,:
Robert, Can you throw any light on this? Or do you have any further
comments on the docs?
http://developer.postgresql.org/pgdocs/postgres/dynamic-trace.html
Here is what the dtrace man page says about the -32 and -64 flags:
The D compiler prod
Hi,
I've have attached a patch along with two new files.This patch should
reflect what we discussed at the Summit. Please let me know if I miss
anything.
There are a few potential/known issues which I need help from the gurus.
1) The current logic in src/backend/Makefile will only work for S
.
---
Robert Lor wrote:
Hi Bruce,
The new SPARC assembly file src/backend/port/tas/solaris_sparc.s uses /
instead of ! for comments, and as a result the compile fails with Sun
Studio 11. Please modify the first 3 lines to look like the
Hi Bruce,
The new SPARC assembly file src/backend/port/tas/solaris_sparc.s uses /
instead of ! for comments, and as a result the compile fails with Sun
Studio 11. Please modify the first 3 lines to look like the following.
!==
21 matches
Mail list logo
