Re: amcheck (B-Tree integrity checking tool)
От | Robert Haas |
---|---|
Тема | Re: amcheck (B-Tree integrity checking tool) |
Дата | |
Msg-id | CA+TgmobcqVdf2UZ6R+3w321CBGdhrVfnyNCmmc7NdGLXsAtEHg@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, Nov 18, 2016 at 6:51 PM, Peter Geoghegan <pg@heroku.com> wrote: > On Thu, Nov 17, 2016 at 12:04 PM, Peter Geoghegan <pg@heroku.com> wrote: >>> Hm, if we want that - and it doesn't seem like a bad idea - I think we >>> should be make it available without recompiling. >> >> I suppose, provided it doesn't let CORRUPTION elevel be < ERROR. That >> might be broken if it was allowed. > > 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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: