Thread: Re: [PATCHES] Dynamic Tracing docs
"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.
regards, tom lane
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/
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
Also, it is probably too late to add something of this magnitude this close to wrapping the tarball, but I might be mistaken. --------------------------------------------------------------------------- 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. > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 7: You can help support the PostgreSQL project by donating at > > http://www.postgresql.org/about/donate -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +