On Mon, Jun 16, 2014 at 12:14 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> On Sun, Jun 15, 2014 at 6:29 PM, Christoph Berg <cb@df7cb.de> wrote:
>>
>> Re: Amit Kapila 2014-06-13
>> <CAA4eK1KLn1SmgVtd=5emAbQxrrPVeEdTBUU94E-rEPMwxWVL+A@mail.gmail.com>
>> > Agreed, I had mentioned in Notes section of document. Apart from that
>> > I had disallowed parameters that are excluded from postgresql.conf by
>> > initdb (Developer options) and they are recommended in user manual
>> > to be not used in production.
>>
>> Excluding developer options seems too excessive to me. ALTER SYSTEM
>> should be useful for developing too.
>
> Developer options are mainly for debugging information or might help in one
> of the situations, so I thought somebody might not want them to be part of
> server configuration once they are set. We already disallow parameters like
> config_file, transaction_isolation, etc. which are disallowed to be set in
> postgresql.conf. Could you please explain me a bit in which
> situations/scenarios, do you think that allowing developer options via Alter
> System can be helpful?
I think that's helpful. I've heard that some users enable the developer option
"trace_sort" in postgresql.conf in order to collect the information
about sorting.
They might want to set trace_sort via ALTER SYSTEM, for example.
> This information is not stored in pg_settings. One way is to specify
> manually all the parameters which are disallowed but it seems the query
> will become clumsy, another could be to have another column in pg_settings.
> Do you think of any other way?
I like the latter idea, i.e., exposing the flags of GUC parameters in
pg_settings,
but it seems overkill just for tab-completion purpose. I'd withdraw my comment.
Regards,
--
Fujii Masao
