Re: elog/ereport VS misleading backtrace_function function address

On Tue, May 14, 2024 at 6:13 AM Jakub Wartak
<jakub(dot)wartak(at)enterprisedb(dot)com> wrote:
> OK I'll try to explain using assembly, but I'm not an expert on this.
> Let's go to the 1st post, assume we run with backtrace_function set:

I feel like this explanation doesn't really explain very much. I mean,
the question is not "how is it that adding a nop instruction fixes
anything?" but "is adding a nop instruction a principled way of fixing
things, and if so, for what reason?". And as far as I can see, you
haven't answered that question anywhere. Unless we really understand
why the results are better with that nop instruction added, we can't
possibly have any confidence that this is anything other than random
good fortune, which isn't a sufficiently good reason to make a change.
And, while I'm no expert on this, I suspect that it is mostly just
random good fortune -- the fact that inserting a volatile variable
declaration here solved the problem seems like something that could
easily fail to work out on another platform or compiler or compiler
version. I also think it's the wrong idea on principle to insert junk
declarations into our code to try to get good backtraces.

I think the right answer here is probably what Alvaro said, namely,
that people have to have the debug symbols installed if they want to
get backtraces. Tom is probably correct when he says that there's
nothing we can do to ensure that users end up with debug symbols in
all cases, but that doesn't mean it's the wrong solution. It's at
least understandable why it works.

--
Robert Haas
EDB: http://www.enterprisedb.com