On Wed, Sep 11, 2024 at 09:00:33AM -0400, Robert Haas wrote: > On Tue, Sep 10, 2024 at 4:58 PM Noah Misch <n...@leadboat.com> wrote: > > ... a rule of "each wait event appears in one > > pgstat_report_wait_start()" would be a rule I don't want. > > As the original committer of the wait event stuff, I intended for the > rule that you do not want to be the actual rule. However, I see that I > didn't spell that out anywhere in the commit message, or the commit > itself. > > > I see this level of fine-grained naming > > as making the event name a sort of stable proxy for FILE:LINE. I'd value > > exposing such a proxy, all else being equal, but I don't think wait event > > names like AuthLdapBindLdapbinddn/AuthLdapBindUser are the right way. Wait > > event names should be more independent of today's code-level details. > > I don't agree with that. One of the most difficult parts of supporting > PostgreSQL, in my experience, is that it's often very difficult to > find out what has gone wrong when a system starts behaving badly. It > is often necessary to ask customers to install a debugger and do stuff > with it, or give them an instrumented build, in order to determine the > root cause of a problem that in some cases is not even particularly > complicated. While needing to refer to specific source code details > may not be a common experience for the typical end user, it is > extremely common for me. This problem commonly arises with error > messages
That is a problem. Half the time, error verbosity doesn't disambiguate enough for me, and I need backtrace_functions. I now find it hard to believe how long we coped without backtrace_functions. I withdraw the objection to "each wait event appears in one pgstat_report_wait_start()".
