Re: max_standby_delay considered harmful

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Greg Smith <greg(at)2ndquadrant(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: max_standby_delay considered harmful
Date: 2010-05-05 04:18:38
Message-ID: t2s407d949e1005042118m3c74ee7fif7699cccf897e857@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, May 5, 2010 at 5:01 AM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
> Our process is shot to pieces. But then, we knew that, didn't we ;-)
>

Franky I think these kinds of usability questions are things that
we'll never have great success getting feedback on without users
banging on the system. There are solutions but none of them are
perfect. We a) either let releases go out with functionality that
nobody's sure users will be happy with and promise that the next
release will polish it, b) commit big functionality changes only at
the beginning of the release cycle and live with a two-release cycle
latency for such changes, or c) make last-minute changes during betas.

So far we've seen a combination of (a) and (c). I think (a) has worked
out well, sure we have some non-ideal behaviour in new features but
people forgive and forget when the later releases polish it. I've
always advocated for (b) though, I think we've been lucky with the
cases where we've needed last minute adjustments that they've worked
better than we had a right to expect.

--
greg

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alex Hunsaker 2010-05-05 04:40:27 Re: buildfarm building all live branches from git
Previous Message Andrew Dunstan 2010-05-05 04:01:04 Re: max_standby_delay considered harmful