Re: Overhauling GUCS - Mailing list pgsql-hackers
From | Chris Browne |
---|---|
Subject | Re: Overhauling GUCS |
Date | |
Msg-id | 60bq2emdyu.fsf@dba2.int.libertyrms.com Whole thread Raw |
In response to | Re: Overhauling GUCS (Alvaro Herrera <alvherre@commandprompt.com>) |
List | pgsql-hackers |
gsmith@gregsmith.com (Greg Smith) writes: > On Fri, 6 Jun 2008, Heikki Linnakangas wrote: > >> Or perhaps we should explicitly mark the settings the tool has >> generated, and comment out: >> >> #shared_buffers = 32MB # commented out by wizard on 2008-06-05 >> shared_buffers = 1024MB # automatically set by wizard on 2008-06-05 > > What I would like to do is make the tool spit out a revision history > in the same way I find all "big IT" shops handling this already: by > putting a revision history style commentary above the current setting. > Here's a sample: > > # 2008-03-02 : 32MB : postgres : Database default > # 2008-05-02 : 512MB : pg_autotune : Wizard update > # 2008-05-15 : 1024MB : gsmith : Increased after benchmark tests > shared_buffers = 1024MB > > If the first tuning tool that comes into existance used this format, > and the format was reasonable, I think it would be possible to get > people making manual edits to adopt it as well. My first reaction to this is... "And why is it that you seem to imagine it a good idea to recreate RCS, badly?" While that may be an unkind reaction, I don't think it's a particularly wrong one! Getting into "comment formatting" certainly *does* seem like an attempt to do, poorly, what RCS does. And I am pointing at a tool from 1985 as opposed to "modern" ones to point out that there were better approaches to managing versioning of simple text documents *THIRTY YEARS AGO*. Indeed, CVS, which we are still using doesn't fundamentally do anything, in this context, that RCS didn't. I kind of wish that there was some sort of library for "doing RCS"; even in the absence of that, it would be perfectly logical for a tool that manages this to DEMAND that there be a "diff" utility or some equivalent available. In the absence of that, let me suggest that it would be preferable to follow VMS's lead and, if you "automagically" make any changes, create a version called "postgresql.conf;[n]" where "[n]" is either: a) 1, if "postgresql.conf;1" does not exist, or b) 1 + thelargest integer found. Replace ";" with some other character as need be. Add a line (or a few lines) at the top of the current version that indicates some bit of commented-out-metadata that is obviously formatted and easily recognizable such as: ### [pgauto] postgresql.conf-autotuner - ran 2008-07-02 ### [pgauto] little bit of safely-turfable header ### [pgauto] further little bit of safely-turfable header In effect, what it does is thus: - Keep the old copy as postgresql.conf;24 (because we have some 24 elder versions)- Strips off any leading lines that beginwith "### [pgauto]"- Puts any interesting comments in a set of leading lines that begin with "### [pgauto]" Merits, over some wacky rewrite-comment-formatting:- This requires only the thinnest bit of "special handling" of comments.-It doesn't force in a dependancy on [pick-someone's-pet-SCM that you happen to hate]- Even in the absence of anSCM, it keeps versioning information around- If you have a "diff," it'll work perfectly well, and be reasonably informative-It doesn't throw ANY old data away! Sorry, that's more than enough rant for today! :-) -- "cbbrowne","@","linuxdatabases.info" http://cbbrowne.com/info/rdbms.html Rules of the Evil Overlord #220. "Whatever my one vulnerability is, I will fake a different one. For example, ordering all mirrors removed from the palace, screaming and flinching whenever someone accidentally holds up a mirror, etc. In the climax when the hero whips out a mirror and thrusts it at my face, my reaction will be ``Hmm...I think I need a shave.''" <http://www.eviloverlord.com/>
pgsql-hackers by date: