SEO

Enclose new trace.sgml file as discussed on -docs.

This includes some heavily rewritten words and mostly verbatim programs
from http://blogs.sun.com/robertlor/entry...race_probes_in,
as invited to do by Josh Berkus and Robert Lor on 27 Nov in private
correspondence prior to my post on -docs. There is substantial
additional material as well as genericisation so it is suitable for
inclusion in general docs.

This includes refactoring of some of the trace related GUC docs from
config.sgml, so its all in the one place.

SGML is clean apart from two xrefs that don't work properly:

openjade:config.sgml:4412:23:X: reference to non-existent ID
"TRACE-CONFIG-DEVELOPER"
openjade:wal.sgml:292:31:X: reference to non-existent ID "GUC-WAL-DEBUG"
openjade:/usr/share/sgml/docbook/dsssl-stylesheets/html/dblink.dsl:203:1:E: XRef LinkEnd to missing ID 'TRACE-CONFIG-DEVELOPER'
openjade:/usr/share/sgml/docbook/dsssl-stylesheets/html/dblink.dsl:203:1:E: XRef LinkEnd to missing ID 'GUC-WAL-DEBUG'

Quick fixes?

(I haven't proof-read the resulting .html as a result of the above
error, but seems like y'all would want to see this anyway).

--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com



---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

On Fri, 2006-12-01 at 18:56 -0500, Tom Lane wrote:
> "Simon Riggs" <simon@2ndquadrant.com> writes:
> > This includes refactoring of some of the trace related GUC docs from
> > config.sgml, so its all in the one place.
>
> Why exactly is that a good idea?

All of the trace options that require code edits to enable them are in
one place now. No need to re-invent what is already there.

> Since DTrace is Solaris-only, this
> almost seems like an attempt to hide non-Solaris-specific information
> where people won't look for it.

The chapter is about Trace generally. DTrace isn't the only way of
getting trace information out of the server, so why would it have it's
own private chapter?

> Moreover, the point of config.sgml
> is to describe all the configuration parameters in one place. We do not
> need to have people second-guessing that decision for random subsets
> of the parameters.

I had split the Developer options into 2, which was a neat split. There
are tracing parameters and recovery/other parameters. So the split was
neither random, nor hidden - there was a clear xref to them from the
config.sgml. (That was one of the causes of the SGML errors, note).

The trace related parameters are significantly different from other
parameters, since they do not always work.

--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com



---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

"Simon Riggs" <simon@2ndquadrant.com> writes:
> Enclose new trace.sgml file as discussed on -docs.

After some thought I decided it's probably best to stick this into
monitoring.sgml for now. If it gets big enough to deserve its own
chapter we can think about where else to put it.

Committed with some rewording and SGML fixes.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

On Sat, 2006-12-02 at 01:02 +0100, Guillaume Lelarge wrote:
> Simon Riggs a écrit :
> > Enclose new trace.sgml file as discussed on -docs.
> >
> > This includes some heavily rewritten words and mostly verbatim programs
> > from http://blogs.sun.com/robertlor/entry...race_probes_in,
> > as invited to do by Josh Berkus and Robert Lor on 27 Nov in private
> > correspondence prior to my post on -docs. There is substantial
> > additional material as well as genericisation so it is suitable for
> > inclusion in general docs.
> >
> > This includes refactoring of some of the trace related GUC docs from
> > config.sgml, so its all in the one place.
> >
> > SGML is clean apart from two xrefs that don't work properly:
> >
> > openjade:config.sgml:4412:23:X: reference to non-existent ID
> > "TRACE-CONFIG-DEVELOPER"
> > openjade:wal.sgml:292:31:X: reference to non-existent ID "GUC-WAL-DEBUG"
> > openjade:/usr/share/sgml/docbook/dsssl-stylesheets/html/dblink.dsl:203:1:E: XRef LinkEnd to missing ID 'TRACE-CONFIG-DEVELOPER'
> > openjade:/usr/share/sgml/docbook/dsssl-stylesheets/html/dblink.dsl:203:1:E: XRef LinkEnd to missing ID 'GUC-WAL-DEBUG'
> >
>
> Don't you need to lowercase them ? at least guc-wal-config exists in
> config.sgml, but in lowercase only.
>
> grep -ir shows nothing about a TRACE-CONFIG-DEVELOPER ID. In
> config.sgml, there is a runtime-config-developer but I don't know if
> this is the one you're searching for.

They are lower case.

--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com



---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

On Dec 1, 2006, at 6:56 PM, Tom Lane wrote:

> "Simon Riggs" <simon@2ndquadrant.com> writes:
>> This includes refactoring of some of the trace related GUC docs from
>> config.sgml, so its all in the one place.
>
> Why exactly is that a good idea? Since DTrace is Solaris-only, this
> almost seems like an attempt to hide non-Solaris-specific information
> where people won't look for it. Moreover, the point of config.sgml
> is to describe all the configuration parameters in one place. We
> do not
> need to have people second-guessing that decision for random subsets
> of the parameters.

There is high likelihood that DTrace will be present in FreeBSD 7.0
and Mac OS 10.5. So, 3 of the support platforms would make use of it.

// Theo Schlossnagle
// CTO -- http://www.omniti.com/~jesus/
// OmniTI Computer Consulting, Inc. -- http://www.omniti.com/



---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Oh, seems like Tom got it into CVS. Good.

---------------------------------------------------------------------------

Simon Riggs wrote:
> Enclose new trace.sgml file as discussed on -docs.
>
> This includes some heavily rewritten words and mostly verbatim programs
> from http://blogs.sun.com/robertlor/entry...race_probes_in,
> as invited to do by Josh Berkus and Robert Lor on 27 Nov in private
> correspondence prior to my post on -docs. There is substantial
> additional material as well as genericisation so it is suitable for
> inclusion in general docs.
>
> This includes refactoring of some of the trace related GUC docs from
> config.sgml, so its all in the one place.
>
> SGML is clean apart from two xrefs that don't work properly:
>
> openjade:config.sgml:4412:23:X: reference to non-existent ID
> "TRACE-CONFIG-DEVELOPER"
> openjade:wal.sgml:292:31:X: reference to non-existent ID "GUC-WAL-DEBUG"
> openjade:/usr/share/sgml/docbook/dsssl-stylesheets/html/dblink.dsl:203:1:E: XRef LinkEnd to missing ID 'TRACE-CONFIG-DEVELOPER'
> openjade:/usr/share/sgml/docbook/dsssl-stylesheets/html/dblink.dsl:203:1:E: XRef LinkEnd to missing ID 'GUC-WAL-DEBUG'
>
> Quick fixes?
>
> (I haven't proof-read the resulting .html as a result of the above
> error, but seems like y'all would want to see this anyway).
>
> --
> Simon Riggs
> EnterpriseDB http://www.enterprisedb.com
>

[ Attachment, skipping... ]

[ Attachment, skipping... ]

>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings

--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

Simon Riggs wrote:
> Enclose new trace.sgml file as discussed on -docs.

I have a question here, regarding this:

To include DTrace support in a 64-bit binary, specify --enable-dtrace
and DTRACEFLAGS="-64" to configure.

The dtrace documentation says that dtrace automatically picks the right
build environment. Something is wrong here. Either the dtrace
documentation or ours.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

On Sat, 2006-12-02 at 09:43 +0100, Peter Eisentraut wrote:
> Simon Riggs wrote:
> > Enclose new trace.sgml file as discussed on -docs.
>
> I have a question here, regarding this:
>
> To include DTrace support in a 64-bit binary, specify --enable-dtrace
> and DTRACEFLAGS="-64" to configure.
>
> The dtrace documentation says that dtrace automatically picks the right
> build environment. Something is wrong here. Either the dtrace
> documentation or ours.

I didn't presume to question Robert's technical notes
http://blogs.sun.com/robertlor/entry...race_probes_in

Robert, Can you throw any light on this? Or do you have any further
comments on the docs?
http://developer.postgresql.org/pgdo...mic-trace.html

--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com



---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

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/pgdo...mic-trace.html
>
>
Here is what the dtrace man page says about the -32 and -64 flags:

The D compiler produces programs using the native data
model of the operating system kernel. You can use the
isainfo -b command to determine the current operating
system data model. If the -32 option is specified,
dtrace forces the D compiler to compile a D program
using the 32-bit data model. If the -64 option is speci-
fied, dtrace forces the D compiler to compile a D pro-
gram using the 64-bit data model. These options are typ-
ically not required as dtrace selects the native data
model as the default. The data model affects the sizes
of integer types and other language properties. D pro-
grams compiled for either data model can be executed on
both 32-bit and 64-bit kernels. The -32 and -64 options
also determine the ELF file format (ELF32 or ELF64) pro-
duced by the -G option.

In my testing on the 64 bit Solaris kernel building a 64-bit Postgres
binary, if DTRACEFLAGS="-64" is not passed to the configure script,
compilation will fail when dtrace is invoked. Based on my observation,
dtrace will default to 32-bit, but for 64-bit you have to be explicit
with DTRACEFLAGS="-64"

Simon, thanks for you help with the doc patch!

Regards,
-Robert



---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings