On Tue, Oct 27, 2009 at 10:53 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> I guess all I'm saying is that if we took the approach of making SET >> PERSISTENT rewrite postgresql.conf, we actually could let people do it >> either way they pleased without the complexity of having multiple >> files. > > You keep saying that, but what you don't seem to get is that that > amounts to telling the people who want to go slow that they should > go jump in a lake. The moment they even experiment with SET PERSISTENT, > everything they've ever done with postgresql.conf goes up in smoke. > This is not going to be acceptable.
I guess I didn't consider the possibility that someone might reuse an 8.4 postgresql.conf on an 8.5 server. That could be awkward. But even if they do, it's not *nearly* as bad as "everything they've ever done with postgresql.conf goes up in smoke". I was thinking that the algorithm would be something like: "Read the old postgresql.conf and write it back out to a new file line by line. If, in the process of doing this, you find a setting for the variable you're trying to change, then write out the new line in place of the original line. If you subsequently find anymore output lines that set that same variable, then skip writing them to the output file altogether. If you get to the end of the file without finding the setting you're trying to change, then append a new line setting that variable to the specified value." If someone uses this on a setting that already exists - uncommented - in their legacy postgresql.conf file, then at most they will lose any comment on the same line as the setting they changed. The new setting will end up on the same line in the new file as the old one, with all the same comments around it. If someone uses this on a setting that does not exist in their legacy postgresql.conf file, the new setting will just be appended to the end, while the rest of the file will remain unchanged. At worst, they'll be surprised that the setting ended up not where they were expecting it to be - but if they were expecting SET PERSISTENT to notice where the commented-out version of the setting was and put the new value there, they're going to be disappointed under any implementation we're likely to settle on (having the new setting in a different file altogether doesn't seem better, at least not to me). > Furthermore, that approach is not especially simple from the tools' > standpoint either, because then the minimum bar for doing anything at > all is the ability to parse postgresql.conf, remove conflicting old > settings, and add your own. Even without any comment support, that is > an order of magnitude harder than just dropping a prebuilt file into a > directory, which is feasible for at least some use-cases with the > directory approach. True, but actually having a good SET PERSISTENT command would solve most of this problem, because the tools could just use that. The ability to just drop in a file is superficially attractive, but I think it's a red herring. Whatever settings the tool sets will still potentially be set elsewhere in other files (maybe even files created by other tools). So tool A comes and drops in a file that sets work_mem, checkpoint_segments, and wal_buffers, and then tool B comes along and sets max_connections, a couple of autovacuum settings, and checkpoint_segments again. Then tool C comes along and does something else again, and now the DBA wants to change a setting with SET PERSISTENT, while the other DBA edits postgresql.conf using $EDITOR. We may have tools to tell you which file is providing the value for any particular parameter, but I don't think they're going to make this kind of situation un-confusing. Normally, you're going to want the value for any particular parameter to be the one the value to which it was most recently changed, and that just won't be the case with this setup, at least not without some pretty substantial gymnastics. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
