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);
+ TRACE_POSTGRESQL_LWLOCK_WAIT_DONE(T_NAME(lo
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 file.
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 depending on the call site, as
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 i
On Tue, Oct 13, 2015 at 3:47 PM, Robert Haas wrote:
> On Tue, Aug 18, 2015 at 12:08 PM, Alvaro Herrera
> wrote:
>> Robert Haas wrote:
>>> On Sat, Aug 15, 2015 at 6:45 PM, Mark Johnston wrote:
>>
>>> > The bug is in src/backend/Makefile. probes.o, the dtrace(1)-generated
>>> > object file, depend
On Tue, Aug 18, 2015 at 12:08 PM, Alvaro Herrera
wrote:
> Robert Haas wrote:
>> On Sat, Aug 15, 2015 at 6:45 PM, Mark Johnston wrote:
>
>> > The bug is in src/backend/Makefile. probes.o, the dtrace(1)-generated
>> > object file, depends on the objfiles.txt for each of the backend
>> > subdirs. Th
Robert Haas wrote:
> On Sat, Aug 15, 2015 at 6:45 PM, Mark Johnston wrote:
> > The bug is in src/backend/Makefile. probes.o, the dtrace(1)-generated
> > object file, depends on the objfiles.txt for each of the backend
> > subdirs. These files depend in turn on the object files themselves; if
> >
On Sat, Aug 15, 2015 at 6:45 PM, Mark Johnston wrote:
> There seems to be a bug in the make rules when DTrace is enabled. It
> causes dtrace -G to be invoked twice when building PostgreSQL as a
> FreeBSD port: once during the build itself, and once during
> installation. For a long time this has b
Hi,
There seems to be a bug in the make rules when DTrace is enabled. It
causes dtrace -G to be invoked twice when building PostgreSQL as a
FreeBSD port: once during the build itself, and once during
installation. For a long time this has been worked around on FreeBSD
with a change to libdtrace it
--On 14. November 2009 15:25:25 +0100 Zdenek Kotala
wrote:
Hmm, const is also problem on solaris. dtrace generates probe.h file and
eats const. It generates following noise on solaris build:
"postgres.c", line 554: warning: argument #1 is incompatible with
prototype:
prototype: poi
Hmm, const is also problem on solaris. dtrace generates probe.h file and
eats const. It generates following noise on solaris build:
"postgres.c", line 554: warning: argument #1 is incompatible with
prototype:
prototype: pointer to char : "../../../src/include/utils/probes.h",
line 582
I'm just seeing these kind of compiler warnings in current HEAD:
pgstat.c: In function ‘pgstat_report_activity’:
pgstat.c:2276: warning: passing argument 1 of
‘__dtrace_probe$postgresql$statement__status$v1$63686172202a’ discards
qualifiers from pointer target type
There are more of them (e.g
Tom Lane 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 Systemtap guys th
Joshua Tolley 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 that. I've be
On Thu, May 28, 2009 at 06:28:14PM -0400, Tom Lane wrote:
> Joshua Tolley 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 doubl
Joshua Tolley 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", "transaction__commit", etc.
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
Robert Lor 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 Probes" sectio
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 c
Greg Stark writes:
> On Tue, Mar 24, 2009 at 9:31 PM, Robert Lor 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 ex
On Tue, Mar 24, 2009 at 10:53 PM, Martijn van Oosterhout
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
(__builtin_constant_p(__x) || __builti
On Tue, Mar 24, 2009 at 10:18:08PM +, Greg Stark wrote:
> On Tue, Mar 24, 2009 at 10:12 PM, Martijn van Oosterhout
> 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
On Tue, Mar 24, 2009 at 10:12 PM, Martijn van Oosterhout
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 complex express
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 ma
On Tue, Mar 24, 2009 at 9:31 PM, Robert Lor 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 expressions.
I'm starting
Tom Lane wrote:
Zdenek Kotala 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 argum
Dne 17.03.09 19:49, Tom Lane napsal(a):
Zdenek Kotala 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 depen
Zdenek Kotala 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 arguments.
More s
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
per
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 OS
Patch applied. Thanks.
---
Robert Lor wrote:
> Attached is the doc patch for the recently added probes.
>
> -Robert
>
> Index: doc/src/sgml/monitoring.sgml
> =
Attached is the doc patch for the recently added probes.
-Robert
Index: doc/src/sgml/monitoring.sgml
===
RCS file: /projects/cvsroot/pgsql/doc/src/sgml/monitoring.sgml,v
retrieving revision 1.63
diff -u -3 -p -r1.63 monitoring.sgml
Thanks, applied.
---
Robert Lor wrote:
> Tom Lane wrote:
> > Robert Lor writes:
> >
> >> Tom Lane wrote:
> >>
> >>> I agree. If the probe is meant to track only *some* WAL writes
> >>> then it needs to be named som
Tom Lane wrote:
Robert Lor 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
Robert Lor 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
> TRACE_POSTGRESQL
Tom Lane wrote:
"Fujii Masao" 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
TRACE_POSTGRESQL_WAL_BUFFER_WRITE.
H
"Fujii Masao" writes:
> On Thu, Dec 18, 2008 at 4:49 AM, Robert Lor 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 empty WAL buffer pages available,
Hi,
On Thu, Dec 18, 2008 at 4:49 AM, Robert Lor 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 wan
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
Robert Lor escribió:
> Fujii Masao wrote:
>> Hi,
>>
>> On Wed, Dec 17, 2008 at 4:53 AM, Robert Lor 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 deter
Fujii Masao wrote:
Hi,
On Wed, Dec 17, 2008 at 4:53 AM, Robert Lor 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 m
Hi,
On Wed, Dec 17, 2008 at 4:53 AM, Robert Lor 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 much as we
> absol
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
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
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':
> storage/buffer/bufmgr.o(.
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 -
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:
http://www.postgresql.org/mailpref/pgsql-hack
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 abou
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 machine.
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 pgsql-hac
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
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 p
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'v
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 h
Robert Lor <[EMAIL PROTECTED]> writes:
> Bruce Momjian wrote:
>> Do we need to add detection logic to catch buggy versions?
>>
> Instead of adding extra logic, I think it's sufficient with
> documentation since the issue will soon be fixed in the next Solaris update.
I agree ... it's not like th
Bruce Momjian wrote:
Do we need to add detection logic to catch buggy versions?
Instead of adding extra logic, I think it's sufficient with
documentation since the issue will soon be fixed in the next Solaris update.
Regards,
-Robert
---(end of broadcast)
Robert Lor wrote:
> Peter Eisentraut wrote:
>
> >That rings a bell. Can we get a more precise designation on what
> >version of DTrace we support? And where can one get that required
> >update?
> >
> >
> >
> Peter,
>
> The problem with static function was fixed recently and is now available
Peter Eisentraut wrote:
That rings a bell. Can we get a more precise designation on what
version of DTrace we support? And where can one get that required
update?
Peter,
The problem with static function was fixed recently and is now available
in Solaris Express (the development versio
Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Does it not like static functions?
>
> I seem to recall Robert mentioning that they'd only recently fixed
> DTrace to cope with probes in static functions. Maybe you need to
> get an update?
That rings a bell. Can we get a more p
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Does it not like static functions?
I seem to recall Robert mentioning that they'd only recently fixed
DTrace to cope with probes in static functions. Maybe you need to
get an update?
regards, tom lane
---
/usr/sbin/dtrace -G -s utils/probes.d access/SUBSYS.o bootstrap/SUBSYS.o
catalog/SUBSYS.o parser/SUBSYS.o commands/SUBSYS.o executor/SUBSYS.o
lib/SUBSYS.o libpq/SUBSYS.o main/SUBSYS.o nodes/SUBSYS.o optimizer/SUBSYS.o
port/SUBSYS.o postmaster/SUBSYS.o regex/SUBSYS.o rewrite/SUBSYS.o
storage/SU
There is work going on to add dtrace support to FreeBSD, which I expect
could migrate to the other BSDs as well. AFAIK *BSD is actually more
popular among the developers than linux, so dtrace support could well
happen.
On Mon, Nov 07, 2005 at 02:29:12PM -0700, Aly Dharshi wrote:
> From what I unde
From what I understand DTrace is rather tough to use. Secondly it will provide
Solaris only information, so if you are suggesting helpfulness for just Solaris,
then yes it would be. I don't think that DTrace is available for Solaris 8 and
9, the company I work for is still on 8 with possibly som
I skimmed the thread "Spinlocks, yet again: analysis
and proposed patches". Wouldn't Solaris 10's DTrace
be helpful in seeing what's going on? It seems DTrace
was meant for these types of problems.
__
Yahoo! FareChase: Search multiple travel sit
On 6/17/05, Josh Berkus 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 around to this
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
Agl
66 matches
Mail list logo
