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
performance penalty which depends on number of arguments.
See the code:
FlushBuffer+0x69: call +0x128c6 <smgropen>
FlushBuffer+0x6e: addl $0x10,%esp
FlushBuffer+0x71: movl %eax,0xc(%ebp)
FlushBuffer+0x74: subl $0x4,%esp
FlushBuffer+0x77: movl 0xc(%ebp),%eax
FlushBuffer+0x7a: pushl 0x8(%eax)
FlushBuffer+0x7d: pushl 0x4(%eax)
FlushBuffer+0x80: pushl (%eax)
FlushBuffer+0x82: nop
FlushBuffer+0x83: nop
FlushBuffer+0x84: nop
FlushBuffer+0x85: nop
FlushBuffer+0x86: nop
FlushBuffer+0x87: addl $0x10,%esp
nops reserve space for probe.
For better explanation see:
http://blogs.sun.com/ahl/entry/user_land_tracing_gets_better
Zdenek
Dne 13.03.09 15:15, Tom Lane napsal(a):
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 X, so it's not clear what I did
wrong. Can anyone with a Solaris machine poke into it, at least
to the extent of finding out where it's dumping core?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
