Re: amcheck (B-Tree integrity checking tool)

On Sat, Nov 19, 2016 at 11:38 PM, Peter Geoghegan <pg(at)heroku(dot)com> wrote:
> On Sat, Nov 19, 2016 at 6:45 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>> What do you think about new argument with default vs. GUC? I guess
>>> that the GUC might be a lot less of a foot-gun. We might even give it
>>> a suitably scary name, to indicate that it will make the server PANIC.
>>> (I gather that you don't care about other aspects of verbosity -- just
>>> about the ability to make amcheck PANIC in the event of an invariant
>>> violation without recompiling it.)
>>
>> Yikes. I don't think I want to expose any kind of API that lets the
>> user PANIC the server. A value < ERROR sounds far more reasonable
>> than a value > ERROR.
>
> In general, I don't want to get into the business of reasoning about
> how well we can limp along when there is a would-be error condition
> within amcheck. Once "the impossible" has actually occurred, it's very
> difficult to reason about what still works. Also, I actually agree
> that making it possible for the tool to force a PANIC through a
> user-visible interface is a bad idea.
>
> Maybe we should just leave it as it is -- experts can recompile the
> tool after modifying it to use an elevel that is != ERROR (the thing I
> mention about elevel < ERROR is already documented in code comments).
> If that breaks, they get to keep both halves.

OK. If it's not reasonable to continue checking after an ERROR, then
I think ERROR is the way to go. If somebody really doesn't like that
lack of flexibility (in either direction), they can propose a change
later for separate consideration. That limitation is not, in my view,
a sufficient reason to hold up the patch on the table.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company