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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers