elog a stack trace

Lists: Postg스포츠 토토 사이트SQL
From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: elog a stack trace
Date: 2014-05-02 15:16:39
Message-ID: CAMkU=1wCVL53o+ye-bX8UO41gPJESimNJGGvbc1u7qqe3VXOOw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: Postg스포츠 토토 사이트SQL

Does anyone have any hints on how to get a stack trace programmatically,
rather than trying to run ps to get the pid and then attach gdb to a
ephemeral process and hoping the situation has not been changed while you
are doing that? I'd like to set

log_error_verbosity = stack

or

elog_stack(,...)

But those don't exist.

Cheers,

Jeff


From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: elog a stack trace
Date: 2014-05-02 15:18:35
Message-ID: 20140502151835.GA12715@awork2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Hi,

On 2014-05-02 08:16:39 -0700, Jeff Janes wrote:
> Does anyone have any hints on how to get a stack trace programmatically,
> rather than trying to run ps to get the pid and then attach gdb to a
> ephemeral process and hoping the situation has not been changed while you
> are doing that? I'd like to set
>
> log_error_verbosity = stack
>
> or
>
> elog_stack(,...)

There's backtrace() on several platforms. The stacktraces are less
detailed than what gdb gives you tho.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services


From: "MauMau" <maumau307(at)gmail(dot)com>
To: "Jeff Janes" <jeff(dot)janes(at)gmail(dot)com>, "pgsql-hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: elog a stack trace
Date: 2014-05-06 05:10:44
Message-ID: C13F6A104761484EB9EC35D78A56F524@maumau
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

From: "Jeff Janes" <jeff(dot)janes(at)gmail(dot)com>
> Does anyone have any hints on how to get a stack trace programmatically,
> rather than trying to run ps to get the pid and then attach gdb to a
> ephemeral process and hoping the situation has not been changed while you
> are doing that? I'd like to set
>
> log_error_verbosity = stack
>
> or
>
> elog_stack(,...)
>
> But those don't exist.

On Windows, you can use Stackwalk() or Stackwalk64() Win32 API. Several
years ago, for some software, I implemented a feature that outputs the stack
trace of a crashing process to its server log file.

It would be very nice if PostgreSQL outputs the stack trace of a crashing
postgres process in the server log. That eliminates the need for users in
many cases to send the huge core files to the support staff or to use the
debugger to get the stack trace. I've recently heard that MySQL has this
feature.

Regards
MauMau


From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: MauMau <maumau307(at)gmail(dot)com>
Cc: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: elog a stack trace
Date: 2014-05-06 16:32:08
Message-ID: 20140506163208.GU6018@eldon.alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

MauMau wrote:

> On Windows, you can use Stackwalk() or Stackwalk64() Win32 API.
> Several years ago, for some software, I implemented a feature that
> outputs the stack trace of a crashing process to its server log
> file.
>
> It would be very nice if PostgreSQL outputs the stack trace of a
> crashing postgres process in the server log. That eliminates the
> need for users in many cases to send the huge core files to the
> support staff or to use the debugger to get the stack trace. I've
> recently heard that MySQL has this feature.

+1, assuming it can be made to work reliably and does not cause a larger
reliability problem. I see the GNU extension to get backtraces, for
instance, tries to malloc stuff in order to get a human-readable trace,
which might not be all that great.

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services