On Mon, Jan 19, 2015 at 10:39 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> I think whichever process reads postgresql.conf/postgresql.auto.conf have
> to do this (unless we restrict that this will be done at some other time)
> and
> postmaster is one of them. It seems to me that it is not good idea unless
> we do it at other time like populating entries for a view.
Well, the postmaster does not have database access, and neither do
most of the auxiliary processes. The autovacuum launcher has very
limited database access (shared catalogs only).
Making the postmaster access the database is a complete non-starter;
we have worked very hard to avoid that, for reasons of overall system
robustness. If the postmaster crashes or locks up, manual
intervention is required; if any other process crashes, the postmaster
can reset the whole system.
>> Independently of that, it sounds like solving the problem from the
>> wrong end. I think the idea of ALTER SYSTEM .. SET ought to be that
>> you should EITHER edit postgresql.conf for all your configuration
>> changes, OR you should use ALTER SYSTEM .. SET for all of your
>> changes. If you mix-and-match, well, that's certainly allowed and it
>> will work and everything, but you - as a human being - might get
>> confused.
>
> Right, but we can't completely eliminate such a possibility (as an
> example we have some default settings like max_connections,
> shared_buffers, etc). I agree with you that users should use only
> way of changing the settings, however for certain rare cases (default
> settings or some other) we can provide a way for user to know which
> of the settings are duplicate. I think if we can provide such an
> information via some view with ease then it's worth to have it.
I'd suggest abandoning the idea of storing anything in a persistent
basis in a system catalog and look for some way for the backend to
which the user is connected to expose its own state instead. For
example, pg_settings already exposes "sourcefile" and "sourceline"
settings. Actually, I'm not quite sure why that's not sufficient
here, but if it isn't, it could be extended.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company