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

On 2013-01-26 07:46:50 -0500, Robert Haas wrote:
> On Thu, Jan 24, 2013 at 12:39 PM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> > More people seem to have voted for the single file approach but I still
> > haven't understood why...
>
> Me neither. Having an include directory seems good, but I can't think
> why we'd want to clutter it up with a bajillion automatically
> generated files. One .auto file that gets overwritten at need seems
> way nicer.

I unfortunately think you misunderstood what I meant. I don't really see
that many arguments for putting all the variables in a single file. That
is I think the one-value-per-file is preferrable.

The primary reason is that the multiple values per file is just
considerably harder to implement without POLA. In order to not loose
values set in this or other backends you basically need to do something
like:

1) exlusive lock
2) reload config file (to update in memory structures)
3) check new variable
4) write config file (needs to be done atomically)
5) optionally reload config file
6) reload lock

Where as you can get acceptable behaviour in the single-value-per-file
approach by:
1) check new config variable
2) write new single-variable file
3) optionally reload config file

Not requiring a global lock while reading the configuration seems to
make stuff noticeably simpler.

The other advantages for a single value approach I know of are:
* way easier to integrate into other systems, no need to parse the whole
file for them
* easier to get yourself out of problems if you screwed up and set a bad
value (shared_buffers=16TB instead of GB ;))

Whereas the only real argument I can see for the all-in-one-file
approach I can see is that it will perform better.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services