From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | Martijn van Oosterhout <kleptog(at)svana(dot)org>, Alvaro Herrera <alvherre(at)2ndquadrant(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>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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-27 03:34:00 |
Message-ID: | CAA4eK1+U+OqePB24Ze16TtUysp3Ff05GnFKa2RB6+x9WhcWzyw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Aug 26, 2013 at 10:50 PM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> Martijn,
>
> * Martijn van Oosterhout (kleptog(at)svana(dot)org) wrote:
>> Note, my whole purpose for suggesting something like:
>>
>> include_auto_conf_file postgresql.auto.conf
>>
>> is because I want the file location to be configurable. If I put in my
>> configuration:
>>
>> include_auto_conf_file /etc/postgresql/9.4/postgresql.auto.conf
>
> I'm not following the use-case here.
>
> Why would it make sense for a file which is entirely managed by PG
> automatically to be in /etc? Of course, by the same token you might ask
> why it makes sense to let the user pick it at all, which holds some
> merit- but I liked your idea because then an admin doesn't have to go
> looking for the file but instead knows where it is. Perhaps comments in
> the file stating where the auto.conf lives would be sufficient, but
> those are too often nuked. :(
>
>> it better put the options there. And if I comment the line out ALTER
>> SYSTEM should stop working. If I put it at the beginning of the config
>> then any other option in the file will override it (which we can detect
>> and warn about). If I put it at the end of the file, ALTER SYSTEM
>> overrides any statically configured options.
>>
>> And I can imagine hosting providers putting the configuration for
>> memory usage, shared library directories and other such options after,
>> and options like cpu_cost, enable_merge_join, etc before. That way
>> they have fine grained control over which options the user can set and
>> which not.
>
> For my part, I'd honestly rather have the first things found be what's
> picked and later things be ignored. If you want it controlled by ALTER
> SYSTEM, then don't set it in postgresql.conf. The problem with that is
> there's no "bootstrap" mechanism without actually modifying such configs
> or making the configs be in auto.conf to begin with, neither of which is
> ideal, imv.
>
> I really hate the idea that someone could configure 'X' in
> postgresql.conf and because the auto.conf line is later in the file,
> it's able to override the original setting. Does not strike me as
> intuitive at all.
This is currently how include mechanism works in postgresql.conf,
changing that for this special case can be costly and moreover the
specs for this patch were layout from beginning that way.
However, we can have some mechanism for appending values (if feasible)
as suggested in mail below, after initial patch is done
http://www.postgresql.org/message-id/52015414.9060900@cybertec.at
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Boszormenyi Zoltan | 2013-08-27 06:04:44 | Re: UNNEST with multiple args, and TABLE with multiple funcs |
Previous Message | David Rowley | 2013-08-27 03:06:29 | Patch: Allow formatting in log_line_prefix |