Simon Riggs wrote:
> On Mon, 2010-05-03 at 11:37 -0400, Tom Lane wrote:
>
>> I've finally wrapped my head around exactly what the max_standby_delay
>> code is doing, and I'm not happy with it.
>
> Yes, I don't think I'd call it perfect yet.
>
>> have the slave cancel competing queries if the replay process waits
>> more than max_standby_delay seconds to acquire a lock. This is simple,
>> understandable, and behaves the same whether we're reading live data or
>> not.
>
> I have no objection, and would welcome, adding another behaviour, since
> that just gives us a better chance of having this feature do something
> useful.
>
>> I'm inclined to think that we should throw away all this logic
>
> HS has been through 2 Alphas with the current behaviour and it will go
> through 0 Alphas with the newly proposed behaviour. At this stage of
> proceedings, that is extremely dangerous and I don't wish to do that.
> The likelihood that we replace it with something worse seems fairly
> high/certain: snap decision making never quite considers all angles.
> Phrases like "throw away all this logic" don't give me confidence that
> people that agree with that perspective would understand what they are
> signing up to.
I'm not really sure how much serious testing outside of the small set of
people mostly interested in one or another specific aspect of HS/SR has
been actually done with the alphas to be honest.
I just started testing HS yesterday and I already ran twice into the
general issue tom is complaining about with max_standby_delay...
Stefan
