Skip site navigation (1) Skip section navigation (2)

Re: Uh, I change my mind about commit_delay + commit_siblings (sort of)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Peter Geoghegan <peter(at)2ndquadrant(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Uh, I change my mind about commit_delay + commit_siblings (sort of)
Date: 2012-06-28 19:00:06
Message-ID: 1608.1340910006@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Thu, Jun 28, 2012 at 2:18 PM, Peter Geoghegan <peter(at)2ndquadrant(dot)com> wrote:
>> You think it will confuse users less if we start telling them to use
>> something that we have a very long history of telling them not to use?

> I don't buy this line of reasoning at all.  If we're going to rename
> the GUC, it should be for accuracy, not PR value.  If we start
> renaming something every time we improve it, we're going to go nuts.
> We improved lots of things in 9.2; they didn't all get renamed.

See VACUUM FULL for a recent counterexample --- we basically jacked it
up and drove a new implementation underneath, but we didn't change the
name, despite the fact that we were obsoleting a whole lot more folk
knowledge than exists around commit_delay.

Of course, there were application-compatibility reasons not to rename
that command, which wouldn't apply so much to commit_delay.  But still,
we have precedent for expecting that we can fix external documentation
rather than trying to code around whatever it says.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Josh BerkusDate: 2012-06-28 19:03:15
Subject: Re: We probably need autovacuum_max_wraparound_workers
Previous:From: Peter GeogheganDate: 2012-06-28 18:58:15
Subject: Re: Uh, I change my mind about commit_delay + commit_siblings (sort of)

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group