On Mon, May 10, 2010 at 6:03 AM, Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> wrote: > Robert Haas wrote: >> On Thu, May 6, 2010 at 2:47 PM, Josh Berkus <j...@agliodbs.com> wrote: >>>> Now that I've realized what the real problem is with max_standby_delay >>>> (namely, that inactivity on the master can use up the delay), I think >>>> we should do what Tom originally suggested here. It's not as good as >>>> a really working max_standby_delay, but we're not going to have that >>>> for 9.0, and it's clearly better than a boolean. >>> I guess I'm not clear on how what Tom proposed is fundamentally >>> different from max_standby_delay = -1. If there's enough concurrent >>> queries, recovery would never catch up. >> >> If your workload is that the standby server is getting pounded with >> queries like crazy, then it's probably not that different: it will >> fall progressively further behind. But I suspect many people will set >> up standby servers where most of the activity happens on the primary, >> but they run some reporting queries on the standby. If you expect >> your reporting queries to finish in <10s, you could set the max delay >> to say 60s. In the event that something gets wedged, recovery will >> eventually kill it and move on rather than just getting stuck forever. >> If the volume of queries is known not to be too high, it's reasonable >> to expect that a few good whacks will be enough to get things back on >> track. > > Yeah, I could live with that. > > A problem with using the name "max_standby_delay" for Tom's suggestion > is that it sounds like a hard limit, which it isn't. But if we name it > something like: > > # -1 = no timeout > # 0 = kill conflicting queries immediately > # > 0 wait for N seconds, then kill query > standby_conflict_timeout = -1 > > it's more clear that the setting is a timeout for each *conflict*, and > it's less surprising that the standby can fall indefinitely behind in > the worst case. If we name the setting along those lines, I could live > with that.
+1 from the peanut gallery. -- Mike Rylander | VP, Research and Design | Equinox Software, Inc. / The Evergreen Experts | phone: 1-877-OPEN-ILS (673-6457) | email: mi...@esilibrary.com | web: http://www.esilibrary.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
