Re: elog/ereport VS misleading backtrace_function function address

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Jakub Wartak <jakub(dot)wartak(at)enterprisedb(dot)com>
Cc: Peter Eisentraut <peter(at)eisentraut(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Subject: Re: elog/ereport VS misleading backtrace_function function address
Date: 2024-05-14 15:36:05
Message-ID: CA+Tgmobkkmwt-6DzdF8rB7Hxfxs1ytzq6vYQXT5Ug64q0LQiUw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2024-05-14 15:53:46 Re: Extend pgbench partitioning to pgbench_history
Previous Message Robert Haas 2024-05-14 15:17:43 Re: Dump-restore loosing 'attnotnull' bit for DEFERRABLE PRIMARY KEY column(s).