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.
> Putting in something that tries to maintain a closed-loop maximum
> delay between master and slave seems like a topic for future research
> rather than a feature we have to have in 9.0. And in any case we'd
> still want the plain max delay for non-SR cases, AFAICS, because there's
> no sane way to use closed-loop logic in other cases.
I will be looking for ways to improve this over time.
-- Simon Riggs www.2ndQuadrant.com
