From: Chris Browne <cbbrowne@acm.org>
To: pgsql-hackers@postgresql.org
Subject: Re: Overhauling GUCS
Date: Fri, 06 Jun 2008 17:48:57 -0400
Message-ID: <60bq2emdyu.fsf@dba2.int.libertyrms.com> (raw)
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>
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/;
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: cbbrowne@acm.org
Subject: Re: Overhauling GUCS
In-Reply-To: <60bq2emdyu.fsf@dba2.int.libertyrms.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox