Re: max_standby_delay considered harmful

Robert Haas wrote:
> On Sat, May 8, 2010 at 3:40 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> > Robert Haas wrote:
> >> On Sat, May 8, 2010 at 2:48 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> >> > I think the concensus is to change this setting to a boolean. ?If you
> >> > don't want to do it, I am sure we can find someone who will.
> >>
> >> I still think we should revert to Tom's original proposal.
> >
> > And Tom's proposal was to do it on WAL slave arrival time? ?If we could
> > get agreement from everyone that that is the proper direction, fine, but
> > I am hearing things like plugins, and other complexity that makes it
> > seem we are not getting closer to an agreed solution, and without
> > agreement, the simplest approach seems to be just to remove the part we
> > can't agree upon.
> >
> > I think the big question is whether this issue is significant enough
> > that we should ignore our policy of no feature design during beta.
>
> Tom's proposal was basically to define recovery_process_lock_timeout.
> The recovery process would wait X seconds for a lock, then kill
> whoever held it. It's not the greatest knob in the world for the
> reasons already pointed out, but I think it's still better than a
> boolean and will be useful to some users. And it's pretty simple.

I thought there was concern about lock stacking causing
unpredictable/unbounded delays. I am not sure boolean has a majority
vote, but I am suggesting that because it is the _minimal_ feature set,
and when we can't agree during beta, the minimal feature set seems like
the best choice.

Clearly, anything is more feature-full than boolean --- the big question
is whether Tom's proposal is significantly better than boolean that we
should spend the time designing and implementing it, with the
possibility it will all be changed in 9.1.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com