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

From Michael Paquier
Subject Re: Tracking wait event for latches
Date
Msg-id CAB7nPqQ6OQB321e_EojGTtVX01mq0riwsLZXrWifuwvwdAbvjg@mail.gmail.com
Whole thread Raw
In response to Re: Tracking wait event for latches  (Alexander Korotkov <a.korotkov@postgrespro.ru>)
Responses Re: Tracking wait event for latches  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Mon, Aug 22, 2016 at 6:09 PM, Alexander Korotkov
<a.korotkov@postgrespro.ru> wrote:
> Hi, Michael!
>
> On Thu, Aug 4, 2016 at 8:26 AM, Michael Paquier <michael.paquier@gmail.com>
> wrote:
> I took a look at your patch. Couple of notes from me.

Thanks!

>> const char *
>> GetEventIdentifier(uint16 eventId)
>> {
>> const char *res;
>> switch (eventId)
>> {
>> case EVENT_ARCHIVER_MAIN:
>> res = "ArchiverMain";
>> break;
>> ... long long list of events ...
>> case EVENT_WAL_SENDER_WRITE_DATA:
>> res = "WalSenderWriteData";
>> break;
>> default:
>> res = "???";
>> }
>> return res;
>> }
>
>
> Would it be better to use an array here?

The reason why I chose this way is that there are a lot of them. It is
painful to maintain the order of the array elements in perfect mapping
with the list of IDs...

>> typedef enum EventIdentifier
>> {
>
>
> EventIdentifier seems too general name for me, isn't it?  Could we name it
> WaitEventIdentifier? Or WaitEventId for shortcut?

OK. So WaitEventIdentifier? The reason to include Identifier is for
consistency with lwlock structure notation.
-- 
Michael



pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: improved DefElem list processing
Next
From: Amit Kapila
Date:
Subject: Re: dsm_unpin_segment