Re: [PATCHES] Dynamic Tracing docs
От | Simon Riggs |
---|---|
Тема | Re: [PATCHES] Dynamic Tracing docs |
Дата | |
Msg-id | 1165023224.3778.970.camel@silverbirch.site обсуждение исходный текст |
Ответ на | Re: [PATCHES] Dynamic Tracing docs (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: