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 escribió:
> * Alvaro Herrera (alvherre(at)2ndquadrant(dot)com) wrote:
> > Well, all the relative paths in include/includedir directives would be
> > relative to the directory specified by the -c config_file param, which
> > makes perfect sense. So the conf.d would work fine in your example.
>
> Why would include/includedir directives be relative to where the
> 'config_file' GUC is set to instead of relative to where all the other
> GUCs in postgresql.conf are relative to? That is a recipe for
> confusion, imv.
>
> 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."

> 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.

> > The only problem I see in your snippet above is the "include auto.conf"
> > line, which doesn't make any sense because that file would not be found.
>
> 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.

> 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.

> While I really like the 'include auto.conf' style, I'm starting to think
> it may not be workable after all. Another thing to consider is if the
> user decides to change that include line.. What happens when the DBA
> tries to do a 'ALTER SYSTEM'? It'd still use the hard-coded auto.conf
> file and happily update it, I imagine, but it won't actually get
> included...

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.

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services