Re: postgresql.auto.conf read from wrong directory

On Mon, Jun 16, 2014 at 12:14 PM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> On Sun, Jun 15, 2014 at 6:29 PM, Christoph Berg <cb(at)df7cb(dot)de> wrote:
>>
>> Re: Amit Kapila 2014-06-13
>> <CAA4eK1KLn1SmgVtd=5emAbQxrrPVeEdTBUU94E-rEPMwxWVL+A(at)mail(dot)gmail(dot)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