On Mon, Jan 19, 2015 at 10:39 PM, Amit Kapila <amit.kapil...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers