Re: Tracking wait event for latches - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Tracking wait event for latches
Date
Msg-id CAB7nPqRwVCnLgthpB16THrs=1xQ1nOG95qOqG44ogMe6V=4W3Q@mail.gmail.com
Whole thread Raw
In response to Re: Tracking wait event for latches  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Tracking wait event for latches  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Wed, Sep 28, 2016 at 9:45 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Wed, Sep 28, 2016 at 8:38 AM, Michael Paquier
> <michael.paquier@gmail.com> wrote:
>> So should I change back the patch to have only one argument for the
>> eventId, and guess classId from it?
>
> Why would you need to guess?

Incorrect wording from me perhaps? i just meant that processing needs
to know what is the classId coming for a specific eventId.

> But, yes, I think one argument is much preferable.

OK. Here is the wanted patch. I have reduced the routines of WaitLatch
& friends to use only one argument, and added what is the classId
associated with a given eventId in an array of multiple fields, giving
something like that:
+ const struct wait_event_entry WaitEventEntries[] = {
+   /* Activity */
+   {WAIT_ACTIVITY, "ArchiverMain"},
[...]

I have cleaned up as well the inclusions of pgstat.h that I added
previously. Patch is attached.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: Speed up Clog Access by increasing CLOG buffers
Next
From: Peter Eisentraut
Date:
Subject: Re: PATCH: Exclude additional directories in pg_basebackup