Re: max_standby_delay considered harmful

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: max_standby_delay considered harmful
Date: 2010-05-04 13:12:48
Message-ID: 20100504131248.GI21875@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

* Simon Riggs (simon(at)2ndQuadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2010-05-04 13:36:25 Re: Pause/Resume feature for Hot Standby
Previous Message Pavel Stehule 2010-05-04 11:53:00 Re: what is good solution for support NULL inside string_to_array function?