Re: amcheck (B-Tree integrity checking tool)
От | Peter Geoghegan |
---|---|
Тема | Re: amcheck (B-Tree integrity checking tool) |
Дата | |
Msg-id | CAM3SWZRGycL9t9GSSQPb2L5Zaxt-4ZnrFi35FRghvdOeetWs-g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: amcheck (B-Tree integrity checking tool) (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: amcheck (B-Tree integrity checking tool)
|
Список | pgsql-hackers |
On Sat, Nov 19, 2016 at 6:45 PM, Robert Haas <robertmhaas@gmail.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. -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: