From: | Peter Geoghegan <pg(at)heroku(dot)com> |
---|---|
To: | Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com> |
Cc: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru> |
Subject: | Re: amcheck (B-Tree integrity checking tool) |
Date: | 2016-03-12 00:45:48 |
Message-ID: | CAM3SWZTpG=xGrNAtQfEa6Ofwqzq2gAqieLEfKC_UJUAXGcb9GA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Mar 11, 2016 at 4:30 PM, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Chris Ruprecht | 2016-03-12 01:42:20 | OS X 10.11.3, psql, bus error 10, 9.5.1 |
Previous Message | Peter Geoghegan | 2016-03-12 00:40:14 | Re: amcheck (B-Tree integrity checking tool) |