Re: [HACKERS] Runtime Partition Pruning - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] Runtime Partition Pruning
Date
Msg-id 17881.1558714137@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] Runtime Partition Pruning  (Andres Freund <andres@anarazel.de>)
Responses Re: [HACKERS] Runtime Partition Pruning
Re: [HACKERS] Runtime Partition Pruning
List pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On 2019-05-24 11:34:58 -0400, Tom Lane wrote:
>> Hmm, after some digging in the archives, the closest thing I can find
>> is this thread:
>>
https://www.postgresql.org/message-id/flat/CAMsr%2BYGL%2ByfWE%3DJvbUbnpWtrRZNey7hJ07%2BzT4bYJdVp4Szdrg%40mail.gmail.com
>> where we discussed using libunwind instead, but people didn't like
>> the extra dependency.

> Hm, I didn't actually see that much concern about that. I still think we
> should just go for libunwind.

Is it actually better?  The basic problem with backtrace() is that it
only knows about global functions, and so reports call sites in static
functions as if they were in whatever global function physically precedes
the static one.  I think doing materially better requires depending on
debug symbols, which (at least in the Red Hat world) aren't going to
be there in a typical production situation.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [HACKERS] Runtime Partition Pruning
Next
From: didier
Date:
Subject: Re: [HACKERS] Small fix: avoid passing null pointers to memcpy()