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

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])
Дата
Msg-id 20130820180251.GP2706@tamriel.snowman.net
обсуждение исходный текст
Ответ на 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>)
Ответы 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>)
Список 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 по дате отправления:

Предыдущее
От: "David E. Wheeler"
Дата:
Сообщение: Re: CAST Within EXCLUSION constraint
Следующее
От: Kevin Grittner
Дата:
Сообщение: Re: Detail part for still waiting for lock log message