On Tue, Jan 20, 2015 at 9:38 PM, Robert Haas <robertmh...@gmail.com> wrote: > > 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; >
Okay and I was also not in favour of this approach. > > 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. Agreed. > 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. > The reason why "sourcefile" and "sourceline" are not sufficient is that they can only give the information about the setting in last file it is present. Assume max_connections (or any other setting) is available in both postgresql.conf and postgresql.auto.conf, then it will display the information about the setting in postgresql.auto.conf, so now user might not be able to decide whether that is the setting he want to retain unless he knows the information about setting in postgresql.conf. Now as I have suggested upthread, that we can have a new view pg_file_settings which will display information about settings even when there exists multiple entries for the same in different files. I think adding such information to existing view pg_settings would be difficult as the same code is used for show commands which we don't want to change. With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
