On Wed, Jun 20, 2018 at 12:10 PM, Andres Freund <and...@anarazel.de> wrote: > I think the problem is that this most frequently is an issue when > investigating an issue for customers. Often enough it'll legally not be > possible to gain direct access to the system, and remotely instructing > people to install an extension and configure it isn't great. So if we > could, by default, include something better for PANICs etc, it'd be a > great boon - I think that's even clear from conversionations on the pg > lists (which often will be the more knowledgable people: How often did > we try hard to get a backtrace from a crash?
+1 to all of that. This is a real nuisance, and making it less of a nuisance would be great. > If we instead had a backtrace enabled for all PANICs and some FATALs by > default (and perhaps a SIGSEGV handler too), we'd be in a better > place. That'd obviously only work when compiled with support for > libraries, on platforms where we added support for that. But I think > that'd be quite the improvement already. I think doing it on PANIC would be phenomenal. SIGSEGV would be great if we can make it safe enough, which I'm not sure about, but then I suppose we're crashing anyway. Instead of making the ERROR behavior conditional on log_error_verbosity as Craig has it now, how about doing it whenever the error code is ERRCODE_INTERNAL_ERROR? That's pretty much the cases that aren't supposed to happen, so if we see those happening a lot, it's either a bug we need to fix or we should supply a better error code. Also, a lot of those messages are duplicated in many places and/or occur inside fairly generic functions inside lsyscache.c, so the actual error message text tends not to be enough to know what happened. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company