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.
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.
If we do (1), we'll be having this discussion all over again in
September, and will be no better off because we won't have any
production feedback on Simon's approach. If we do (2) we can hedge it
in the documentation with requirements and cautions, and hopefully only
dedicated DBAs will touch it, and we'll get good feedback from them on
how we should redesign it for 9.1. And if it works as badly as Tom
expects, then we won't have an issue with maintaining backwards
compatibility, because people will be *happy* to change.
One way to communicate this would be to have 2 GUCs instead of one:
allow_query_cancel = on|off # defaults to on
max_standby_timeout = 0 # SEE DOCS BEFORE CHANGING
We named this release 9.0 because, among other things, we expected it to
be less stable than the prior 3 releases. And we can continue to tell
users that. I know I won't be moving any of my clients to 9.0.0.
I said it before and I'll say it again: "release early, release often".
-- -- Josh Berkus PostgreSQL Experts Inc.
http://www.pgexperts.com