On Sat, Nov 19, 2016 at 11:38 PM, Peter Geoghegan <p...@heroku.com> wrote: > On Sat, Nov 19, 2016 at 6:45 PM, Robert Haas <robertmh...@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.
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
