Re: postgresql.auto.conf and reload

On Sat, Jul 5, 2014 at 8:22 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> writes:
> > Please find the patch attached to address the above concern. I have
> > updated docs, so that users can be aware of such behaviour.
>
> I'm in the camp that says that we need to do something about this, not
> just claim that it's operating as designed. AFAICS, the *entire* argument
> for having ALTER SYSTEM at all is ease of use; but this behavior is not
> what I would call facilitating ease of use. In particular, if you are
> conveniently able to edit postgresql.conf, what the heck do you need
> ALTER SYSTEM for?
>
> One possible answer is to modify guc-file.l so that only the last value
> supplied for any one GUC gets processed.

Another could be that during initdb all the uncommented settings be
written to postgresql.auto.conf file rather than to postgresql.conf.
I think we can do this by changing code in initdb.c->setup_config().
This will ensure that unless user is changing settings in a mixed way
(some by Alter System and some manually by editing postgresql.conf),
there will no such problem.

> The naive way of doing that
> would be O(N^2) in the number of uncommented settings, which might or
> might not be a problem; if it is, we could no doubt devise a smarter
> data structure.

Okay. To implement it, we can make sure during parsing Configfile
that only unique element can be present in list. We can modify
function ParseConfigFp() to achieve this functionality. Another
way could be that after the list is formed, we can eliminate
duplicate entries from it, we might need to do this at multiple places.
Do you have anything else in mind?

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com