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:

Previous
From: Robert Lor
Date:
Subject: Re: New DTrace probes proposal
Next
From: Andreas Pflug
Date:
Subject: Re: Overhauling GUCS