Re: [HACKERS] dtrace probes

On 04/20/2017 10:30 AM, Jesper Pedersen wrote: I think this fix is harmless and has some value in terms of consistency. One minor suggestion is that you should leave a space after typecasting. - TRACE_POSTGRESQL_LWLOCK_WAIT_DONE(T_NAME(lock), mode); +

Re: [HACKERS] dtrace probes

Hi, On 04/20/2017 09:24 AM, Amit Kapila wrote: The lwlock dtrace probes define LWLockMode as int, and the TRACE_POSTGRESQL_LWLOCK methods are called using both a variable and constant definition. This leads to a mix of argument definitions depending on the call site, as seen in probes.txt

Re: [HACKERS] dtrace probes

On Tue, Apr 18, 2017 at 9:38 PM, Jesper Pedersen wrote: > Hi, > > The lwlock dtrace probes define LWLockMode as int, and the > TRACE_POSTGRESQL_LWLOCK methods are called using both a variable and > constant definition. > > This leads to a mix of argument definitions

[HACKERS] dtrace probes

Hi, The lwlock dtrace probes define LWLockMode as int, and the TRACE_POSTGRESQL_LWLOCK methods are called using both a variable and constant definition. This leads to a mix of argument definitions depending on the call site, as seen in probes.txt file. A fix is to explicit cast 'mode' to

Re: [HACKERS] Dtrace probes documentation

Tom Lane t...@sss.pgh.pa.us writes: [...] See http://blog.endpoint.com/2009/05/postgresql-with-systemtap.html for details. Perhaps it's worth noting in the documentation that SystemTap users will need to use the double-underscore version? I think a better solution is to persuade the

Re: [HACKERS] Dtrace probes documentation

Joshua Tolley eggyk...@gmail.com writes: On Thu, May 28, 2009 at 06:28:14PM -0400, Tom Lane wrote: Read 26.4.3 and .4. I don't know why they have this bizarre set of conventions, but the single-hyphen version is the spelling most visible to end users. I thought it might be something like

[HACKERS] Dtrace probes documentation

The dtrace probes documentation [1] spells each probe name with dashes (transaction-start, transaction-commit, etc.). Yet as far as I can see, dtrace only works if you spell the probe names with double underscores (transaction__start, transaction__commit, etc.). Why the discrepancy? Obvious patch

Re: [HACKERS] Dtrace probes documentation

Joshua Tolley eggyk...@gmail.com writes: The dtrace probes documentation [1] spells each probe name with dashes (transaction-start, transaction-commit, etc.). Yet as far as I can see, dtrace only works if you spell the probe names with double underscores (transaction__start,

Re: [HACKERS] Dtrace probes documentation

On Thu, May 28, 2009 at 06:28:14PM -0400, Tom Lane wrote: Joshua Tolley eggyk...@gmail.com writes: The dtrace probes documentation [1] spells each probe name with dashes (transaction-start, transaction-commit, etc.). Yet as far as I can see, dtrace only works if you spell the probe names

Re: [HACKERS] DTrace probes broken in HEAD on Solaris?

Robert Lor robert@sun.com writes: Tom Lane wrote: [ complaining about disabled probes not being no-ops ] 1) Only use if (foo_ENABLED()) test for probes with expensive function call/computation in arguments. This will keep the code clean, and we can document this in the Definine New

Re: [HACKERS] DTrace probes broken in HEAD on Solaris?

Dne 24.03.09 22:31, Robert Lor napsal(a): I think the is-enabled test will address the issues you encountered. I see a few alternative to fixing this: 1) Only use if (foo_ENABLED()) test for probes with expensive function call/computation in arguments. This will keep the code clean, and we

Re: [HACKERS] DTrace probes broken in HEAD on Solaris?

Tom Lane wrote: Zdenek Kotala zdenek.kot...@sun.com writes: Answer why it happens when probes are disabled is, that for user application there are piece of code which prepare DTrace probes arguments which will be passed into kernel DTrace modul. This code has performance penalty which

Re: [HACKERS] DTrace probes broken in HEAD on Solaris?

On Tue, Mar 24, 2009 at 9:31 PM, Robert Lor robert@sun.com wrote: I think the is-enabled test will address the issues you encountered. I see a few alternative to fixing this: Another option is to impose a policy that all arguments to probes must be simple local variables -- no

Re: [HACKERS] DTrace probes broken in HEAD on Solaris?

On Tue, Mar 24, 2009 at 09:49:50PM +, Greg Stark wrote: I wonder if there's a gcc extension that would let us check if a macro parameter is a simple variable or expression. That would let us enforce the polilcy strictly at build-time. Not really a GCC extension, but you could have the

Re: [HACKERS] DTrace probes broken in HEAD on Solaris?

On Tue, Mar 24, 2009 at 10:12 PM, Martijn van Oosterhout klep...@svana.org wrote: Not really a GCC extension, but you could have the macro check that it can take the address of the arguments, which amounts to almost the same thing. It only doesn't work on constants. No, there are all kinds of

Re: [HACKERS] DTrace probes broken in HEAD on Solaris?

On Tue, Mar 24, 2009 at 10:18:08PM +, Greg Stark wrote: On Tue, Mar 24, 2009 at 10:12 PM, Martijn van Oosterhout klep...@svana.org wrote: Not really a GCC extension, but you could have the macro check that it can take the address of the arguments, which amounts to almost the same

Re: [HACKERS] DTrace probes broken in HEAD on Solaris?

On Tue, Mar 24, 2009 at 10:53 PM, Martijn van Oosterhout klep...@svana.org wrote: Sorry, I meant to say that the compiler could determine the address at compile time, something like: __builtin_constant_p( !(__x)) ) Hm, that's a better idea. How about something like

Re: [HACKERS] DTrace probes broken in HEAD on Solaris?

Greg Stark st...@enterprisedb.com writes: On Tue, Mar 24, 2009 at 9:31 PM, Robert Lor robert@sun.com wrote: I think the is-enabled test will address the issues you encountered. I see a few alternative to fixing this: Another option is to impose a policy that all arguments to probes must

Re: [HACKERS] DTrace probes broken in HEAD on Solaris?

Dne 17.03.09 19:49, Tom Lane napsal(a): Zdenek Kotala zdenek.kot...@sun.com writes: Answer why it happens when probes are disabled is, that for user application there are piece of code which prepare DTrace probes arguments which will be passed into kernel DTrace modul. This code has

Re: [HACKERS] DTrace probes broken in HEAD on Solaris?

Sorry for late answer, I was on vacation last week. I see that you already fix a problem. Answer why it happens when probes are disabled is, that for user application there are piece of code which prepare DTrace probes arguments which will be passed into kernel DTrace modul. This code has

Re: [HACKERS] DTrace probes broken in HEAD on Solaris?

Zdenek Kotala zdenek.kot...@sun.com writes: Answer why it happens when probes are disabled is, that for user application there are piece of code which prepare DTrace probes arguments which will be passed into kernel DTrace modul. This code has performance penalty which depends on number of

[HACKERS] DTrace probes broken in HEAD on Solaris?

Most of the Solaris buildfarm members are unhappy this morning. It looks like the ones that are busted have --enable-dtrace, which points the finger at the dtrace probe changes I made yesterday: http://archives.postgresql.org/pgsql-committers/2009-03/msg00079.php Those changes work on Linux and

Re: [HACKERS] DTrace probes patch

Thanks, applied. --- Robert Lor wrote: Tom Lane wrote: Robert Lor robert@sun.com writes: Tom Lane wrote: I agree. If the probe is meant to track only *some* WAL writes then it needs to be named

Re: [HACKERS] DTrace probes patch

Tom Lane wrote: Robert Lor robert@sun.com writes: Tom Lane wrote: I agree. If the probe is meant to track only *some* WAL writes then it needs to be named something less generic than TRACE_POSTGRESQL_WAL_BUFFER_WRITE. How about change it to

Re: [HACKERS] DTrace probes patch

Tom Lane wrote: Fujii Masao masao.fu...@gmail.com writes: I understood your intention. But, I think that its function name is somewhat confusing. I agree. If the probe is meant to track only *some* WAL writes then it needs to be named something less generic than

Re: [HACKERS] DTrace probes patch

Robert Lor robert@sun.com writes: Tom Lane wrote: I agree. If the probe is meant to track only *some* WAL writes then it needs to be named something less generic than TRACE_POSTGRESQL_WAL_BUFFER_WRITE. How about change it to TRACE_POSTGRESQL_WAL_BUFFER_WRITE_DIRTY similar to

Re: [HACKERS] DTrace probes patch

Fujii Masao masao.fu...@gmail.com writes: On Thu, Dec 18, 2008 at 4:49 AM, Robert Lor robert@sun.com wrote: My understanding is that we only want to track the XLogWrite when advancing to the next buffer page, and if there is unwritten data in the new buffer page, that indicates no more

Re: [HACKERS] DTrace probes patch

Alvaro Herrera wrote: But there are 5 callers of XLogWrite ... why aren't the other ones being tracked too? This probe originally came from Simon, so it can't possibly be wrong :-) My understanding is that we only want to track the XLogWrite when advancing to the next buffer page, and if

Re: [HACKERS] DTrace probes patch

Robert Lor escribió: Fujii Masao wrote: Hi, On Wed, Dec 17, 2008 at 4:53 AM, Robert Lor robert@sun.com wrote: Why is TRACE_POSTGRESQL_WAL_BUFFER_WRITE_START/DONE called only in AdvanceXLInsertBuffer? We can trace only a part of WAL buffer write? The intention of these probes is to

Re: [HACKERS] DTrace probes patch

Fujii Masao wrote: Hi, On Wed, Dec 17, 2008 at 4:53 AM, Robert Lor robert@sun.com wrote: @@ -1313,12 +1318,14 @@ AdvanceXLInsertBuffer(bool new_segment) * Have to write buffers while holding insert lock. This is * not good,

Re: [HACKERS] DTrace probes patch

Hi, On Thu, Dec 18, 2008 at 4:49 AM, Robert Lor robert@sun.com wrote: Alvaro Herrera wrote: But there are 5 callers of XLogWrite ... why aren't the other ones being tracked too? This probe originally came from Simon, so it can't possibly be wrong :-) My understanding is that we only

Re: [HACKERS] DTrace probes patch

Peter Eisentraut wrote: Robert Lor wrote: The attached patch contains a couple of fixes in the existing probes and includes a few new ones. - Fixed compilation errors on OS X for probes that use typedefs Could you explain what these errors are about? I don't see any errors on my

Re: [HACKERS] DTrace probes patch

Robert Lor wrote: Bruce Momjian wrote: Should I apply this or hold it for 8.5? I think it should go into 8.4 as it also fixes existing problems. I am seeing the following error when linking the backend on a BSD machine: ./../src/port/libpgport_srv.a -lssl -lcrypto -lgetopt

Re: [HACKERS] DTrace probes patch

Bruce Momjian wrote: I am seeing the following error when linking the backend on a BSD machine: ./../src/port/libpgport_srv.a -lssl -lcrypto -lgetopt -ldl -lutil -lm -o postgres storage/buffer/bufmgr.o: In function `ReadBuffer_common':

Re: [HACKERS] DTrace probes patch

Robert Lor wrote: Peter Eisentraut wrote: Robert Lor wrote: The attached patch contains a couple of fixes in the existing probes and includes a few new ones. - Fixed compilation errors on OS X for probes that use typedefs Could you explain what these errors are about? I don't see any

Re: [HACKERS] DTrace probes patch

Bruce Momjian wrote: Should I apply this or hold it for 8.5? I think it should go into 8.4 as it also fixes existing problems. -Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] DTrace probes patch

Robert Lor wrote: The attached patch contains a couple of fixes in the existing probes and includes a few new ones. - Fixed compilation errors on OS X for probes that use typedefs Could you explain what these errors are about? I don't see any errors on my machine. -- Sent via

Re: [HACKERS] DTrace probes patch

Bruce Momjian wrote: I am seeing the following error when linking the backend on a BSD machine: The updated patch attached should fix this problem. My bad for overlooking this. -Robert Index: src/backend/access/transam/xlog.c

Re: [HACKERS] DTrace probes patch

Thanks, applied. --- Robert Lor wrote: Bruce Momjian wrote: I am seeing the following error when linking the backend on a BSD machine: The updated patch attached should fix this problem. My bad for

Re: [HACKERS] DTrace probes patch

Hi, On Wed, Dec 17, 2008 at 4:53 AM, Robert Lor robert@sun.com wrote: @@ -1313,12 +1318,14 @@ AdvanceXLInsertBuffer(bool new_segment) * Have to write buffers while holding insert lock. This is * not good, so only write as

[HACKERS] DTrace probes patch

The attached patch contains a couple of fixes in the existing probes and includes a few new ones. - Fixed compilation errors on OS X for probes that use typedefs - Fixed a number of probes to pass ForkNumber per the relation forks patch - The new probes are those that were taken out from the

Re: [HACKERS] DTrace probes patch

Should I apply this or hold it for 8.5? --- Robert Lor wrote: The attached patch contains a couple of fixes in the existing probes and includes a few new ones. - Fixed compilation errors on OS X for probes that use

Re: [HACKERS] DTrace probes.

On Monday 19 May 2008 11:32:28 Theo Schlossnagle wrote: Howdy, I just saw Robert Lor's patch w.r.t. dtrace probes. It looks very similar in what we've done. We run a nice set of probes in production here that allow us to track the details of checkpointing and statement execution. I've

[HACKERS] DTrace probes.

Howdy, I just saw Robert Lor's patch w.r.t. dtrace probes. It looks very similar in what we've done. We run a nice set of probes in production here that allow us to track the details of checkpointing and statement execution. I've given a few presentations around these probes and have

Re: [HACKERS] DTrace Probes?

On 6/17/05, Josh Berkus josh@agliodbs.com wrote: Hey, Folks, I need to find someone who's really interesed in working with DTrace. Sun has offered to help put DTrace probes into PostgreSQL for advanced profiling, but need to know where to probe. Anyone? I'm afraid that I won't get

[HACKERS] DTrace Probes?

Hey, Folks, I need to find someone who's really interesed in working with DTrace. Sun has offered to help put DTrace probes into PostgreSQL for advanced profiling, but need to know where to probe. Anyone? I'm afraid that I won't get around to this quickly enough. -- --Josh Josh Berkus