Re: Tracking wait event for latches

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Tracking wait event for latches
Date: 2016-09-29 01:40:21
Views: Raw Message | Whole Thread | Download mbox
Lists: pgsql-hackers

On Wed, Sep 28, 2016 at 9:45 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Wed, Sep 28, 2016 at 8:38 AM, Michael Paquier
> <michael(dot)paquier(at)gmail(dot)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.

Attachment Content-Type Size
wait-event-set-v10.patch text/x-diff 32.8 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2016-09-29 01:55:46 Re: PATCH: Exclude additional directories in pg_basebackup
Previous Message Tomas Vondra 2016-09-29 01:10:30 Re: Speed up Clog Access by increasing CLOG buffers