Re: max_standby_delay considered harmful - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: max_standby_delay considered harmful
Date
Msg-id 20100504131248.GI21875@tamriel.snowman.net
Whole thread Raw
In response to Re: max_standby_delay considered harmful  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: max_standby_delay considered harmful
List pgsql-hackers
* Simon Riggs (simon@2ndQuadrant.com) wrote:
> If recovery waits for max_standby_delay every time something gets in its
> way, it should be clear that if many things get in its way it will
> progressively fall behind. There is no limit to this and it can always
> fall further behind. It does result in fewer cancelled queries and I do
> understand many may like that.

Guess I wasn't very clear in my previous description of what I *think*
the change would be (Tom, please jump in if I've got this wrong..).
Recovery wouldn't wait max_standby_delay every time; I agree, that would
be a big change in behaviour and could make it very difficult for the
slave to keep up.  Rather, recovery would proceed as normal until it
encounters a lock, at which point it would start a counting down from
max_standby_delay, if the lock is released before it hits that, then it
will move on, if another lock is encoutered, it would start counting
down from where it left off last time.  If it hits zero, it'll cancel
the other query, and any other queries that get in the way, until it's
caught up again completely.  Once recovery is fully caught up, the
counter would reset again to max_standby_delay.

> That is *significantly* different from how it works now. (Plus: If there
> really was no difference, why not leave it as is?)

Because it's much more complicated the way it is, it doesn't really work
as one would expect in a number of situations, and it's trying to
guarantee something that it probably can't.

> The bottom line is this is about conflict resolution. There is simply no
> way to resolve conflicts without favouring one or other of the
> protagonists. Whatever mechanism you come up with that favours one will,
> disfavour the other. I'm happy to give choices, but I'm not happy to
> force just one kind of conflict resolution.

I don't think anyone is trying to get rid of the knob entirely; you're
right, you can't please everyone all the time, so there has to be some
kind of knob there which people can adjust based on their particular use
case and system.  This is about what exactly the knob is and how it's
implemented and documented.
Thanks,
    Stephen

pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: what is good solution for support NULL inside string_to_array function?
Next
From: Robert Haas
Date:
Subject: Re: Pause/Resume feature for Hot Standby