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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-hackers by date

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