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

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, Andres Freund <andres(at)2ndquadrant(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
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: 2013-08-20 18:02:51
Message-ID: 20130820180251.GP2706@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

* Alvaro Herrera (alvherre(at)2ndquadrant(dot)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 postgres is
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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2013-08-20 18:11:14 Re: Detail part for still waiting for lock log message
Previous Message David E. Wheeler 2013-08-20 16:53:54 Re: CAST Within EXCLUSION constraint