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