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

From Tom Lane
Subject Re: [HACKERS] Runtime Partition Pruning
Date
Msg-id 16535.1558712098@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] Runtime Partition Pruning  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] Runtime Partition Pruning  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
I wrote:
> Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
>> What do people think about adding something like this errbacktrace()
>> from Álvaro's patch to core PostgreSQL?

> I think we did discuss it right after that, or somewhere nearby, and
> concluded that the output is so imprecise that it's not really going
> to be worth whatever portability issues we'd have to deal with.

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.

However, I stand by the assertion that glibc's backtrace() is too
imprecise to be useful; I've experimented with it and despaired of
being able to tell where control had actually been.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Amit Khandekar
Date:
Subject: Re: Minimal logical decoding on standbys
Next
From: Tom Lane
Date:
Subject: Re: Teach pg_upgrade test to honor NO_TEMP_INSTALL