From: Chris Browne <cbbrowne@acm.org>
Subject: Re: Overhauling GUCS
Date: Fri, 06 Jun 2008 17:48:57 -0400
Organization: cbbrowne Computing Inc
Lines: 84
Message-ID: <60bq2emdyu.fsf@dba2.int.libertyrms.com>
References: <20080605162400.GF16502@alvh.no-ip.org>
	<48481CBF.6040602@enterprisedb.com> <48481E3A.4010306@hagander.net>
	<Pine.GSO.4.64.0806051321360.27711@westnet.com>
	<20080605174209.GL16502@alvh.no-ip.org>
	<Pine.GSO.4.64.0806051452480.27254@westnet.com>
	<20080605212129.GI14498@yugib.highrise.ca>
	<Pine.GSO.4.64.0806051725550.10475@westnet.com>
	<3F927D52-A0FD-4575-8D24-F0F70C459235@kineticode.com>
	<4848D447.10005@enterprisedb.com>
	<Pine.GSO.4.64.0806061543200.7804@westnet.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Gnus/5.1008 (Gnus v5.10.8) XEmacs/21.4.21 (linux)
Cancel-Lock: sha1:R6IfuVCiAKpbQHNRHkcsWhCSpF4=
To: pgsql-hackers@postgresql.org

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 + the largest 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 begin with "### [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 an SCM, 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/>