Re: max_standby_delay considered harmful
От | Robert Haas |
---|---|
Тема | Re: max_standby_delay considered harmful |
Дата | |
Msg-id | AANLkTik2jCNECY1FZnYMfYRL0FkpVmSTQkMqUQET4HgJ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: max_standby_delay considered harmful (Josh Berkus <josh@agliodbs.com>) |
Ответы |
Re: max_standby_delay considered harmful
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: