Re: postgresql.auto.conf read from wrong directory - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: postgresql.auto.conf read from wrong directory
Date
Msg-id CAA4eK1KuEY7KaEQg=3Gfm8-bya4V_8ShWbeFRS1GnCWxcKJ9hQ@mail.gmail.com
Whole thread Raw
In response to Re: postgresql.auto.conf read from wrong directory  (Fujii Masao <masao.fujii@gmail.com>)
Responses Re: postgresql.auto.conf read from wrong directory  (Abhijit Menon-Sen <ams@2ndQuadrant.com>)
List pgsql-hackers
On Mon, Jun 16, 2014 at 7:06 PM, Fujii Masao <masao.fujii@gmail.com> wrote:
> > 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.

Okay, if you have usecase where people use such parameters in
postegresql.conf, then it makes sense.  I have removed that restriction
from patch.

> I suggest the following wording:
>
>     This command may not be used to set
>     <xref linkend="guc-data-directory">
>     or any parameters that are not allowed in postgresql.conf.

I think we should not use *may* in this line, because in no
circumstance we will allow this command for the parameters
mentioned.  I have changed it as per your suggestion.

> > +     /*
> > +      * Disallow parameter's that are excluded or disallowed in
> > +      * postgresql.conf.
> > +      */
>
> "parameters", no apostrophe.
okay.
I have changed above comment as earlier comment has
information about developer option which we don't need now.

> >       if ((record->context == PGC_INTERNAL) ||
> > -             (record->flags & GUC_DISALLOW_IN_FILE))
> > -             ereport(ERROR,
> > -                             (errcode(ERRCODE_CANT_CHANGE_RUNTIME_PARAM),
> > -                              errmsg("parameter \"%s\" cannot be changed",
> > -                                             name)));
> > +             (record->flags & GUC_DISALLOW_IN_FILE) ||
> > +             (record->flags & GUC_DISALLOW_IN_AUTO_FILE) ||
> > +             (record->flags & GUC_NOT_IN_SAMPLE))
> > +              ereport(ERROR,
> > +                              (errcode(ERRCODE_CANT_CHANGE_RUNTIME_PARAM),
> > +                               errmsg("parameter \"%s\" cannot be changed",
> > +                                              name)));
>
> I looked at the settings that are marked GUC_NOT_IN_SAMPLE but neither
> PGC_INTERNAL nor GUC_DISALLOW_IN_*FILE. I don't feel strongly about it,
> but I don't see any particularly good reason to exclude them here.

By above do you mean that the patch should allow GUC_NOT_IN_SAMPLE or
something else, if earlier then I have removed it as per comment from Fujji-san. 

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Doing better at HINTing an appropriate column within errorMissingColumn()
Next
From: Peter Geoghegan
Date:
Subject: Re: Doing better at HINTing an appropriate column within errorMissingColumn()