On 2019-Nov-23, Tom Lane wrote:
> I had occasion to try to use errbacktrace() just now, and it blew up
> on me. Investigation finds this:
>
> int
> errbacktrace(void)
> {
> ErrorData *edata = &errordata[errordata_stack_depth];
> MemoryContext oldcont
gular list. Other
>> than that, please go ahead with this.
> Thanks, I added that comment and others, and pushed. Let's see what
> happens now ...
I had occasion to try to use errbacktrace() just now, and it blew up
on me. Investigation finds this:
int
errbacktrace
On 2019-Oct-26, Peter Eisentraut wrote:
> I hadn't realized that you had already attached a patch that implements
> your idea. It looks good to me. Maybe a small comment near
> check_backtrace_functions() why we're not using a regular list. Other
> than that, please go ahead with this.
Thanks,
On 2019-09-30 20:16, Peter Eisentraut wrote:
> On 2019-09-27 17:50, Alvaro Herrera wrote:
>> On 2019-Sep-13, Alvaro Herrera wrote:
>>
>>> On 2019-Aug-20, Peter Eisentraut wrote:
>>>
The memory management of that seems too complicated. The "extra"
mechanism of the check/assign hooks only
On 2019-09-27 17:50, Alvaro Herrera wrote:
> On 2019-Sep-13, Alvaro Herrera wrote:
>
>> On 2019-Aug-20, Peter Eisentraut wrote:
>>
>>> The memory management of that seems too complicated. The "extra"
>>> mechanism of the check/assign hooks only supports one level of malloc.
>>> Using a List seems
On 2019-Sep-13, Alvaro Herrera wrote:
> On 2019-Aug-20, Peter Eisentraut wrote:
>
> > The memory management of that seems too complicated. The "extra"
> > mechanism of the check/assign hooks only supports one level of malloc.
> > Using a List seems impossible. I don't know if you can safely do
ill have
backtraces generated. Finally, the function errbacktrace() can be
manually added to an ereport() call to generate a backtrace for that
call.
Discussion: https://www.postgresql.org/message-id/flat/5f48cb47-bf1e-05b6-7aae-3bf2cd015...@2ndquadrant.com
---
configure
On 2019-08-13 15:24, Alvaro Herrera wrote:
> On 2019-Aug-13, Peter Eisentraut wrote:
>
>> I have changed the configuration setting to backtrace_functions plural,
>> so that you can debug more than one location at once. I had originally
>> wanted to do that but using existing functions like
>> Spl
Peter Eisentraut writes:
> I have changed the configuration setting to backtrace_functions plural,
> so that you can debug more than one location at once. I had originally
> wanted to do that but using existing functions like
> SplitIdentifierString() resulted in lots of complications with error
On 2019-Aug-13, Peter Eisentraut wrote:
> I have changed the configuration setting to backtrace_functions plural,
> so that you can debug more than one location at once. I had originally
> wanted to do that but using existing functions like
> SplitIdentifierString() resulted in lots of complicati
ations in the server. Backtraces are shown on assertion failure.
A new setting backtrace_functions can be set to a list of C function
names, and all ereport()s and elog()s from the functions will have
backtraces generated. Finally, the function errbacktrace() can be
manually added to an ereport() call to
po 12. 8. 2019 v 19:06 odesílatel Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> napsal:
> On 2019-08-12 13:19, Pavel Stehule wrote:
> > If I understand well, backtrace is displayed only when edata->funcname
> > is same like backtrace_function GUC. Isn't it too strong limit?
> >
> > For exam
On 2019-08-12 13:19, Pavel Stehule wrote:
> If I understand well, backtrace is displayed only when edata->funcname
> is same like backtrace_function GUC. Isn't it too strong limit?
>
> For example, I want to see backtrace for all PANIC level errors on
> production, and I would not to limit the sou
Hi
so I agree with unconditionally defining that symbol.
>
> Nitpicking dept: I think in these tests:
>
> + if (!edata->backtrace &&
> + edata->funcname &&
> + backtrace_function[0] &&
> + strcmp(backtrace_function, edata->funcname) == 0)
> + set_backtrace(edata, 2);
>
>
On Tue, Jul 23, 2019 at 6:19 AM Peter Eisentraut
wrote:
> On 2019-07-09 11:43, Peter Eisentraut wrote:
> > After further research I'm thinking about dropping the libunwind
> > support. The backtrace()/backtrace_symbols() API is more widely
> > available: darwin, freebsd, linux, netbsd, openbsd (v
I wrote:
> Just noticing that ExceptionalCondition has an "fflush(stderr);"
> in front of what you added --- perhaps you should also add one
> after the backtrace_symbols_fd call? It's not clear to me that
> that function guarantees to fflush, nor do I want to assume that
> abort() does.
Oh, wait
Peter Eisentraut writes:
> Here is an updated patch without the libunwind support, some minor
> cleanups, documentation, and automatic back traces from assertion failures.
Just noticing that ExceptionalCondition has an "fflush(stderr);"
in front of what you added --- perhaps you should also add o
On 2019-Jul-22, Peter Eisentraut wrote:
> On 2019-07-09 11:43, Peter Eisentraut wrote:
> > After further research I'm thinking about dropping the libunwind
> > support. The backtrace()/backtrace_symbols() API is more widely
> > available: darwin, freebsd, linux, netbsd, openbsd (via port), solari
ort for automatically showing backtraces in certain error
situations in the server. Backtraces are shown on assertion failure.
A new setting backtrace_function can be set to the name of a C
function, and all ereport()s and elog()s from the function will have
backtraces generated. Finally, the function e
After further research I'm thinking about dropping the libunwind
support. The backtrace()/backtrace_symbols() API is more widely
available: darwin, freebsd, linux, netbsd, openbsd (via port), solaris,
and of course it's built-in, whereas libunwind is only available for
linux, freebsd, hpux, solari
On 2019-Jul-08, Dmitry Dolgov wrote:
> > On Sat, Jun 29, 2019 at 7:41 AM Jaime Casanova
> > wrote:
> >
> > This is certainly a very useful thing. Sadly, it doesn't seem to compile
> > when
> > trying to use libunwind.
>
> Yeah, the same for me. To make it works I've restricted libunwind to loc
> On Sat, Jun 29, 2019 at 7:41 AM Jaime Casanova
> wrote:
>
> This is certainly a very useful thing. Sadly, it doesn't seem to compile when
> trying to use libunwind.
Yeah, the same for me. To make it works I've restricted libunwind to local
unwinding only:
#ifdef USE_LIBUNWIND
#define
On Tue, Jun 25, 2019 at 11:08 PM Peter Eisentraut
wrote:
> For the implementation, I support both backtrace() provided by the OS as
> well as using libunwind. The former seems to be supported by a number
> of platforms, including glibc, macOS, and FreeBSD, so maybe we don't
> need the libunwind s
On Tue, 25 Jun 2019 at 06:08, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> New thread continuing from
> <
> https://www.postgresql.org/message-id/d4903af2-e7b7-b551-71f8-3e4a6bdc2...@2ndquadrant.com
> >.
>
> Here is a extended version of Álvaro
On Tue, Jun 25, 2019 at 4:08 AM Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> New thread continuing from
> <
> https://www.postgresql.org/message-id/d4903af2-e7b7-b551-71f8-3e4a6bdc2...@2ndquadrant.com
> >.
>
> Here is a extended version of Álvaro
On 2019-Jun-25, Peter Eisentraut wrote:
> Here is a extended version of Álvaro's patch that adds an errbacktrace()
> function.
Great stuff, thanks for working on it.
> You can do two things with this:
>
> - Manually attach it to an ereport() call site that you want to
New thread continuing from
<https://www.postgresql.org/message-id/d4903af2-e7b7-b551-71f8-3e4a6bdc2...@2ndquadrant.com>.
Here is a extended version of Álvaro's patch that adds an errbacktrace()
function. You can do two things with this:
- Manually attach it to an ereport() call si
27 matches
Mail list logo
