On Thu, May 6, 2010 at 2:47 PM, Josh Berkus <josh@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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
