RE: PATCH: backtraces for error messages - Mailing list pgsql-hackers

From Tsunakawa, Takayuki
Subject RE: PATCH: backtraces for error messages
Date
Msg-id 0A3221C70F24FB45833433255569204D1FA21CCA@G01JPEXMBYT05
Whole thread Raw
In response to Re: PATCH: backtraces for error messages  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
From: Alvaro Herrera [mailto:alvherre@2ndquadrant.com]
> I have no idea how expensive backtrace() and libunwind are, but I doubt
> we want to pay the cost for every message before we know that error
> requires the backtrace to be collected.  Something like PGC_USERSET
>   server_min_backtraces=PANIC
> might be a possible interface.

+1

In addition, it would be nicer if we could have some filtering based on the error condition.  Sometimes I wanted to
knowwhere the "out of memory" or "invalid memory alloc request size ..." was thrown.
 

How about adding a GUC like the -e option of strace?  strace allows to specify which system calls and groups of them to
capture. We can use the SQL state and class code/name to list the conditions to capture.  In the out-of-memory case, I
wantto specify 53200, but don't want to get stack traces for other errors in class 53.
 

https://www.postgresql.org/docs/devel/static/errcodes-appendix.html

Regards
Takayuki Tsunakawa






pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: changing xpath() and xpath_exists()
Next
From: "Tsunakawa, Takayuki"
Date:
Subject: RE: [Proposal] Table-level Transparent Data Encryption (TDE) andKey Management Service (KMS)