Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review]) - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])
Date
Msg-id 20130820180251.GP2706@tamriel.snowman.net
Whole thread Raw
In response to Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
* Alvaro Herrera (alvherre@2ndquadrant.com) wrote:
> Stephen Frost escribió:
> > Of course, the current situation is quite terrible anyway, imv.  Having
> > the GUCs be relative to whereever the user happens to run pg_ctl from is
> > pretty ugly- not to mention that the commented out 'defaults' won't
> > actually work if you uncomment them because the *actual* default/unset
> > value *is* in the data directory.
>
> Uh?  See the docs:
> http://www.postgresql.org/docs/devel/static/config-setting.html#CONFIG-INCLUDES
>
>  " ... the postgresql.conf file can contain include directives, ...
>   If the file name is not an absolute path, it is taken as relative to
>   the directory containing the referencing configuration file."

And what about

http://www.postgresql.org/docs/9.3/static/runtime-config-file-locations.html
... ?
  "When setting any of these parameters, a relative path will be  interpreted with respect to the directory in which
postgresis  started." 

> > I'm starting to wish for a way to do
> > variable substitution inside postgresql.conf, so we could have defaults
> > that would actually work if uncommented (eg: $DataDir/pg_hba.conf).
> >
> > That would help with auto.conf also.
>
> Grumble.  I don't think we need this.  At least, not for ALTER SYSTEM or
> conf.d.

imv, it would be handy.  Along with a $ConfDir which is the
postgresql.conf location- it would certainly make things clearer about
what files are being included from where.

> > To be honest, I was considering 'include' to be relative to the data
> > directory and handled similar to how we process recovery.conf,
>
> Well, recovery.conf is a special case that doesn't follow to normal
> rules.

I don't see why it should be.

> > but as we
> > consider paths in postgresql.conf to be relative to $PWD, that's not
> > ideal because it'd be different from the rest of the file references.
>
> I don't know where you got that idea from, but it's wrong.

Not sure which you're referring to, but see above from the docs?  Also,
please tias..  I was amazed that we use $PWD also, but we do..

> Well, this whole line of discussion started because I objected to the
> whole code path that was trying to detect whether auto.conf had been
> parsed, and raised a warning if ALTER SYSTEM was executed and the file
> wasn't parsed.

I like the idea that we complain if ALTER SYSTEM ends up being
idempotent..  Not sure how far we should take that, but accepting
commands which end up doing nothing is bad, imv.
Thanks,
    Stephen

pgsql-hackers by date:

Previous
From: "David E. Wheeler"
Date:
Subject: Re: CAST Within EXCLUSION constraint
Next
From: Kevin Grittner
Date:
Subject: Re: Detail part for still waiting for lock log message