Hello. Thaks for discussing.
At Mon, 25 Jun 2018 17:08:41 +0800, Craig Ringer wrote
in
> On 25 June 2018 at 14:21, Kyotaro HORIGUCHI > > I think it's pretty strongly desirable for PANIC.
> >
> > Ah, I forgot about that. I agree to that. The cost to collect the
> > information is not a problem
On Sat, Jun 23, 2018 at 8:22 AM, Craig Ringer wrote:
> On 22 June 2018 at 23:26, Korry Douglas
> wrote:
>
>> A few misc comments:
>>
>> In general, +1.
>>
>> It might be nice to move the stack trace code into a separate function
>> (not static to elog.c) - I have often found it useful to attach
On 25 June 2018 at 14:21, Kyotaro HORIGUCHI wrote:
> Hi.
>
> At Mon, 25 Jun 2018 09:32:36 +0800, Craig Ringer
> wrote in gmail.com>
> > On 21 June 2018 at 19:09, Kyotaro HORIGUCHI <
> horiguchi.kyot...@lab.ntt.co.jp
> > > wrote:
> >
> > I think this for assertion failure is no problem but I'm
Hi.
At Mon, 25 Jun 2018 09:32:36 +0800, Craig Ringer wrote
in
> On 21 June 2018 at 19:09, Kyotaro HORIGUCHI > wrote:
>
> I think this for assertion failure is no problem but I'm not sure
> > for other cases.
>
>
> I think it's pretty strongly desirable for PANIC.
Ah, I forgot about that.
On 21 June 2018 at 19:09, Kyotaro HORIGUCHI wrote:
I think this for assertion failure is no problem but I'm not sure
> for other cases.
I think it's pretty strongly desirable for PANIC.
> We could set proper context description or other
> additional information in error messages before just
On 23 June 2018 at 20:22, Craig Ringer wrote:
> Yeah. libunwind doesn't expose any interface to get that information, so
> you'd have to use platform APIs, like glibc's dl_iterate_phdr or dladdr, or
> capture /proc/self/maps.
>
Ahem, I take that part back.
On 22 June 2018 at 23:26, Korry Douglas
wrote:
> A few misc comments:
>
> In general, +1.
>
> It might be nice to move the stack trace code into a separate function
> (not static to elog.c) - I have often found it useful to attach backtraces
> to objects so I can debug complex
A few misc comments:
In general, +1.
It might be nice to move the stack trace code into a separate function (not
static to elog.c) - I have often found it useful to attach backtraces to
objects so I can debug complex allocation/deallocation problems.
The major expense in capturing a stack trace
On 22 June 2018 at 08:48, Andres Freund wrote:
> On 2018-06-22 08:24:45 +0800, Craig Ringer wrote:
> > On Thu., 21 Jun. 2018, 19:26 Pavan Deolasee,
> > wrote:
> >
> > >
> > >
> > > On Thu, Jun 21, 2018 at 11:02 AM, Michael Paquier >
> > > wrote:
> > >
> > >> On Thu, Jun 21, 2018 at 12:35:10PM
On Fri, Jun 22, 2018 at 6:18 AM, Andres Freund wrote:
> On 2018-06-22 08:24:45 +0800, Craig Ringer wrote:
> >
> >
> > Huge +1 from me on being able to selectively manage logging on a
> > module/subsystem, file, or line level.
> >
> > I don't think I saw the post.
> >
> > Such a thing would
On 2018-06-22 08:24:45 +0800, Craig Ringer wrote:
> On Thu., 21 Jun. 2018, 19:26 Pavan Deolasee,
> wrote:
>
> >
> >
> > On Thu, Jun 21, 2018 at 11:02 AM, Michael Paquier
> > wrote:
> >
> >> On Thu, Jun 21, 2018 at 12:35:10PM +0800, Craig Ringer wrote:
> >> > I wrote it because I got sick of
On Thu., 21 Jun. 2018, 19:26 Pavan Deolasee,
wrote:
>
>
> On Thu, Jun 21, 2018 at 11:02 AM, Michael Paquier
> wrote:
>
>> On Thu, Jun 21, 2018 at 12:35:10PM +0800, Craig Ringer wrote:
>> > I wrote it because I got sick of Assert(false) debugging, and I was
>> chasing
>> > down some "ERROR:
On Thu, Jun 21, 2018 at 11:02 AM, Michael Paquier
wrote:
> On Thu, Jun 21, 2018 at 12:35:10PM +0800, Craig Ringer wrote:
> > I wrote it because I got sick of Assert(false) debugging, and I was
> chasing
> > down some "ERROR: 08P01: insufficient data left in message" errors.
> Then I
> > got
Hello, I basically like this.
At Thu, 21 Jun 2018 12:35:10 +0800, Craig Ringer wrote
in
> This is what the stacks look like btw
>
>
> [2018-06-21 12:26:45.309 AWST] [7293] [] [] [:0] DEBUG: 0:
> find_in_dynamic_libpath: trying
> "/home/craig/pg/10/lib/postgresql/pglogical.so"
>
On Thu, Jun 21, 2018 at 12:35:10PM +0800, Craig Ringer wrote:
> I wrote it because I got sick of Assert(false) debugging, and I was chasing
> down some "ERROR: 08P01: insufficient data left in message" errors. Then I
> got kind of caught up in it... you know how it is.
Yes, I know that feeling!
This is what the stacks look like btw
[2018-06-21 12:26:45.309 AWST] [7293] [] [] [:0] DEBUG: 0:
find_in_dynamic_libpath: trying
"/home/craig/pg/10/lib/postgresql/pglogical.so"
[2018-06-21 12:26:45.309 AWST] [7293] [] [] [:0] LOCATION:
find_in_dynamic_libpath, dfmgr.c:639
[2018-06-21
On 21 June 2018 at 01:15, Andres Freund wrote:
> On 2018-06-20 13:10:57 -0400, Robert Haas wrote:
> > On Wed, Jun 20, 2018 at 12:10 PM, Andres Freund
> wrote:
> > > If we instead had a backtrace enabled for all PANICs and some FATALs by
> > > default (and perhaps a SIGSEGV handler too), we'd be
From: Alvaro Herrera [mailto:alvhe...@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
>
On Wed, Jun 20, 2018 at 1:15 PM, Andres Freund wrote:
> I don't think that's ok. It's perfectly possible to hit
> ERRCODE_INTERNAL_ERROR at a high frequency in some situations,
Really? How?
> and
> there's plenty cases that aren't ERRCODE_INTERNAL_ERROR where we'd want
> this. E.g. a lot of
> On 20 Jun 2018, at 17:10, Craig Ringer wrote:
> BTW, Álvaro posted a simpler patch at
> https://www.postgresql.org/message-id/20180410213203.nl645o5vj5ap66sl@alvherre.pgsql.
> It uses backtrace() from glibc, and requires each site you want to bt to be
> annotated explicitly. I forgot about
On 2018-06-20 13:10:57 -0400, Robert Haas wrote:
> On Wed, Jun 20, 2018 at 12:10 PM, Andres Freund wrote:
> > 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
On Wed, Jun 20, 2018 at 12:10 PM, Andres Freund 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
On 2018-06-20 12:04:51 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2018-06-20 11:20:49 -0400, Alvaro Herrera wrote:
> >> 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
Andres Freund writes:
> On 2018-06-20 11:20:49 -0400, Alvaro Herrera wrote:
>> 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
>>
Hi,
On 2018-06-20 11:20:49 -0400, Alvaro Herrera wrote:
> > I recently needed a way to get backtraces from errors in a convenient,
> > non-interactive and indescriminate way. The attached patch is the result.
> > It teaches Pg to use libunwind to self-backtrace in elog/ereport.
> >
> > Anyone
On 06/20/2018 06:10 PM, Craig Ringer wrote:
I recently needed a way to get backtraces from errors in a convenient,
non-interactive and indescriminate way. The attached patch is the
result. It teaches Pg to use libunwind to self-backtrace in elog/ereport.
Anyone think this is
On 2018-Jun-20, Craig Ringer wrote:
> Hi folks
>
> I recently needed a way to get backtraces from errors in a convenient,
> non-interactive and indescriminate way. The attached patch is the result.
> It teaches Pg to use libunwind to self-backtrace in elog/ereport.
>
> Anyone think this is
27 matches
Mail list logo
