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 oldcontext;
>
> Assert(false);
>
Alvaro Herrera writes:
> 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
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
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 a
> malloc-ed array of malloc-ed strings either.
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
On 2019-07-22 20:19, 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), solar
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
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), solaris,
> and of course it's built-in, whereas libunwi
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's patch that adds an errbacktrace()
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's patch that adds an errbacktrace(
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 debug.
>
> - Set a config
26 matches
Mail list logo
