On Thursday, August 01, 2013 8:37 PM Andres Freund wrote:
> Hi,
>
> On 2013-08-01 15:40:22 +0100, Greg Stark wrote:
> > Why isn't it enough to just dump out all variables with a source of
> alter
> > system to a text file? You can either have a single global lock
> around that
> > operation or write it to a new file and move it into place.
>
> It saves you from several complications:
> * No need to iterate over all GUCs, figuring out which come from which
> source, when writing out the file. Not all GUC's, only which are in auto file.
> * Less logic required when writing out a value, since you have an
> acceptable input ready.
> * No need to make sure the autogenerated file is written out in the
> same
> order when adding/changing a setting (to make sure you can
> diff/version control it sensibly)
> * No locking necessary, without locking concurrent changes can vanish.
> * Way easier to delete a setting if it ends up stopping postgres from
> starting. The logic needed in current patch for above points is not all that
complex that it needs to be thought of redesign until the basic idea of
one-file-per-setting scores high over one-file-all-setting.
Below are some points in my mind due to which I have supported/implemented
one-file-all-setting approach:
a. I had heard quite a few times that Postgres has lot of files (each
relation has separate file) as compare to Oracle. Users feel that Oracle's table space approach is better.
b. While server start/Sighup, we needs to open/read/close each file
separately which in-itself seems to be overhead.
I believe what Greg Stark has said in his below mail link is the more
appropriate way and the current patch has done that way.
http://www.postgresql.org/message-id/CAM-w4HP7=a2VowyJUD0CAZL5b8FsaHymdQeouL
udSOhdnCw_zg@mail.gmail.com
Also when other commercial database (Oracle) can do it with single file,
users will try to compare with it.
I understand that our views are not matching on this point and I totally
respect your views, but not able to convince myself
for one-file-per-setting approach. Can you please once again think and see
if there is a viable way for moving forward.
I had modified the patch for many suggestions which had made it simpler and
if you have any idea to make one-file-all-settings
implementation better, then I can address it.
With Regards,
Amit Kapila.
