Re: amcheck (B-Tree integrity checking tool)
От | Robert Haas |
---|---|
Тема | Re: amcheck (B-Tree integrity checking tool) |
Дата | |
Msg-id | CA+TgmobrrYwfGMP1zaH73Vrv6ifWKpDfkJpWsBuKDJOr2Ptqyg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: amcheck (B-Tree integrity checking tool) (Peter Geoghegan <pg@heroku.com>) |
Ответы |
Re: amcheck (B-Tree integrity checking tool)
|
Список | pgsql-hackers |
On Fri, Mar 11, 2016 at 7:45 PM, Peter Geoghegan <pg@heroku.com> wrote: > On Fri, Mar 11, 2016 at 4:30 PM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote: >> Right, but you still have the option to enable them if you don't want to >> swamp your IO system. That's why CIC obeys it too. If I was running a >> consistency check on a production system I'd certainly want the option to >> throttle it. Without that option, I don't see running this on production >> systems as being an option. If that's not a goal then fine, but if it is a >> goal I think it needs to be there. >> >> Isn't it just a few extra lines of code to support it? > > I see your point. > > I'll add that if people like the interface you propose. (Overloading > the VACUUM cost delay functions to cause a delay for amcheck > functions, too). Note that the functions already use an appropriate > buffer access strategy (it avoids blowing shared_buffers, much like > VACUUM itself). I don't particularly like that interface. I also suggest that it would be better to leave throttling to a future commit, and focus on getting the basic feature in first. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: