Re: [PATCH] Identify LWLocks in tracepoints - Mailing list pgsql-hackers

From Dmitry Dolgov
Subject Re: [PATCH] Identify LWLocks in tracepoints
Date
Msg-id 20210501165841.rz4uvavdce6f5w6e@localhost
Whole thread Raw
In response to Re: [PATCH] Identify LWLocks in tracepoints  (Craig Ringer <craig.ringer@enterprisedb.com>)
List pgsql-hackers
> On Fri, Apr 30, 2021 at 11:23:56AM +0800, Craig Ringer wrote:
> On Wed, 14 Apr 2021, 22:29 Robert Haas, <robertmhaas@gmail.com> wrote:
> 
> > > I'm actually inclined to revise the patch I sent in order to *remove*
> > > the LWLock name from the tracepoint argument.
> 
> > Reducing the overheads is good, but I have no opinion on what's
> > important for people doing tracing, because I am not one of those
> > people.
> >
> 
> Truthfully I'm not convinced anyone is "those people" right now. I don't
> think anyone is likely to be making serious use of them due to their
> limitations.

I would like to mention that tracepoints could be useful not only directly,
they also:

* deliver an information about what is important enough to trace from the
  developers, who wrote the code, point of view.

* declare more stable tracing points within the code, which are somewhat more
  reliable between the versions.

E.g. writing bcc scripts one is also sort of limited in use of those
tracepoints because of requirement to provide a specific pid, but still can get
better understanding what to look at (maybe using other methods).



pgsql-hackers by date:

Previous
From: Zhihong Yu
Date:
Subject: Re: Dump public schema ownership & seclabels
Next
From: Alvaro Herrera
Date:
Subject: Re: Enhanced error message to include hint messages for redundant options error