On Wed, Jun 20, 2018 at 12:10 PM, Andres Freund <andres@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