Josh Berkus wrote:
> All,
>
> We are in Beta1, now, and it's May. Original goal for 9.0 was
> June-July. We cannot be introducing major design revisions to HS/SR at
> this date, or we won't ship until December.
>
> There are at least 10 other major features in 9.0, some of which are
> more important to some of our users than HS/SR. More importantly, I
> think the discussion on this thread makes it very clear that no matter
> how much discussion we have on standby delay, we are NOT going to get it
> right the first time. That is, *even if* we replace Simon's code with
> something else, that something else will have as many issues for real
> users as the current delay does, especially since we won't even have
> started debugging or testing the new code yet.
>
> So changing to a lock-based mechanism or designing a plugin interface
> are really not at all realistic at this date.
>
> Realistically, we have two options at this point:
>
> 1) reduce max_standby_delay to a boolean.
I suggest calling it 'delay_wal_application' or 'wal_query_cancel' or
something like that.
> 2) have a delay option (based either on WAL glob start time or on system
> time) like the current max_standby_delay, preferably with some bugs fixed.
I don't think releasing something that many of us can barely understand
is going to help. I think Heikki is right that we might get feedback
from 9.0 that this setting isn't even useful. If we can't get this
right, and it seems we can't, we should just push this to 9.1.
Remember, delaying wal application just delays making the standby a
master and makes the slave data appear staler. We can just tell people
that the larger their queries are, the larger this delay will be. If
they want to control this, they can set 'statement_timeout' already.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
