Heikki, all,
> There's currently three ways to set max_standby_delay:
>
> max_standby_delay = -1 # Query wins
> max_standby_delay = 0 # Recovery wins
> max_standby_delay > X # Query wins until lag > X.
>
> As Tom points out, the 3rd option has all sorts of problems. I very much
> like the behavior that max_standby_delay tries to accomplish, but I have
> to agree that it's not very reliable as it is.
Wow, thanks for the summary. Based on that, I take back what I said to
Greg.
Because I think getting 9.0 out *on time* is more important than any of
these issues, I'm revising my opinion to be more in line with Greg
Smith. So, proposed path forwards.
(1) We work on getting the specific bugs Tom reported fixed.
(2) max_standby_delay default is 0
(3) documentation covers setting it to an integer, but warns extensively
about the required sysadminning and query cancel. As in "for advanced
users only".
(4) discussion of other synch methods gets shifted to 9.0
Ultimately, I think we'll be going to something lock-based like what Tom
suggested. However, I don't think that's doable without delaying 9.0
for 6 months, and I think that would be much worse than any current bug
with 9.0.
No matter how much we tinker with HS/SR, it's not going to be
bulletproof until 9.1. Or, more likely, 9.2.
--
-- 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
