Re: Proposal for Allow postgresql.conf values to be changed via SQL

On Thursday, November 08, 2012 12:28 AM Tom Lane wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> > On Wed, Nov 7, 2012 at 12:29 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> ... we don't normally read the config file within-commands,
> >> and there are both semantic and implementation problems to overcome
> >> if you want to do so.
>
> > Why would you need to? It seems to me that we ought to be able to
> > rewrite a machine-generated configuration file without loading those
> > values into the current session.
>
> Well, Magnus' proposed implementation supposed that the existing values
> *have* been loaded into the current session. I agree that with some
> locking and yet more code you could implement it without that. But this
> still doesn't seem to offer any detectable benefit over value-per-file.

In value-per-file Approach if 2 sessions trying to update same variable
(trying to write in same file),
then won't there be chances that it can corrupt the file if there is no
locking?

Won't this have any impact on base backup/restore, restart and SIGHUP in
terms of that it needs to open,read,close so many files
instead of one file.

"Oracle" and "Git" which provides mechanism to edit of conf file using a
command doesn't use multiple file concept, which indicates that might be
single file concept is better.
Even if we say that user doesn't need to edit or change anything in config
directory, but still some advanced database users/DBA's generally try to
understand the meaning of each folder/file in database to manage it in a
better way. So when we explain them the contents of this folder and
explanation of same, they might not feel good based on their experience with
Oracle or some other similar database.

As per discussion and different opinions "value-per-file" Approach has
merits over "single-file" in terms of design and implementation and
single-file has merits over "value-per-file" in-terms of ugliness (usability
or maintainence or ...)

IMHO, to conclude it, we can see if it is possible to have some not so
complex solution(design) to handle "single-file" Approach then we can use
it, otherwise we can go for "value-per-file" Approach.

With Regards,
Amit Kapila.