Re: amcheck (B-Tree integrity checking tool)

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: amcheck (B-Tree integrity checking tool)
Дата
Msg-id CAM3SWZTpG=xGrNAtQfEa6Ofwqzq2gAqieLEfKC_UJUAXGcb9GA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: amcheck (B-Tree integrity checking tool)  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Ответы Re: amcheck (B-Tree integrity checking tool)  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Re: amcheck (B-Tree integrity checking tool)  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
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).

-- 
Peter Geoghegan



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: amcheck (B-Tree integrity checking tool)
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: Perl's newSViv() versus 64-bit ints?