MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Date: Wed, 12 Jul 2023 16:59:22 +0900
From: Masahiro Ikeda <ikedamsh@oss.nttdata.com>
To: Tristan Partin <tristan@neon.tech>
Cc: pgsql-hackers@lists.postgresql.org
Subject: Re: Support to define custom wait events for extensions
In-Reply-To: <CTZIZDTI9J08.1WLW5E0FWL7LV@gonk>
References: <b9f5411acda0cf15c8fbb767702ff43e@oss.nttdata.com>
 <CTDCV6CIJAKR.TQOTL86K9628@gonk>
 <e4cef41ee00f791c2264f871dc6b5b19@oss.nttdata.com>
 <CTE7JPUIMMBL.2YLT1IWHPUDZ8@gonk>
 <a9eae9af-3834-ceed-33bc-d36c914fef53@oss.nttdata.com>
 <135feae32cd28f9fb555fe46acb939a0@oss.nttdata.com>
 <f3c10c343e6a6080a6b57f0ed25d9e52@oss.nttdata.com>
 <CTZIZDTI9J08.1WLW5E0FWL7LV@gonk>
User-Agent: Roundcube Webmail/1.4.11
Message-ID: <bbc68bc47ecfcc4e0efea5f514f8a6a8@oss.nttdata.com>
Archived-At: 
 <https://www.postgresql.org/message-id/bbc68bc47ecfcc4e0efea5f514f8a6a8%40oss.nttdata.com>
Precedence: bulk

On 2023-07-12 02:39, Tristan Partin wrote:
>> From bf06b8100cb747031959fe81a2d19baabc4838cf Mon Sep 17 00:00:00 2001
>> From: Masahiro Ikeda <masahiro.ikeda.us@hco.ntt.co.jp>
>> Date: Fri, 16 Jun 2023 11:53:29 +0900
>> Subject: [PATCH 1/2] Support custom wait events for extensions.
> 
>> + * This is indexed by event ID minus 
>> NUM_BUILTIN_WAIT_EVENT_EXTENSION, and
>> + * stores the names of all dynamically-created event ID known to the 
>> current
>> + * process.  Any unused entries in the array will contain NULL.
> 
> The second ID should be plural.

Thanks for reviewing. Yes, I'll fix it.

>> +       /* If necessary, create or enlarge array. */
>> +       if (eventId >= ExtensionWaitEventTrancheNamesAllocated)
>> +       {
>> +               int                     newalloc;
>> +
>> +               newalloc = pg_nextpower2_32(Max(8, eventId + 1));
> 
> Given the context of our last conversation, I assume this code was
> copied from somewhere else. Since this is new code, I think it would
> make more sense if newalloc was a uint16 or size_t.

As Michael-san said, I used LWLockRegisterTranche() as a reference.
I think it is a good idea to fix the current master. I'll modify the
above code accordingly.

> From what I undersatnd, Neon differs from upstream in some way related
> to this patch. I am trying to ascertain how that is. I hope to provide
> more feedback when I learn more about it.

Oh, it was unexpected for me. Thanks for researching the reason.

Regards,
-- 
Masahiro Ikeda
NTT DATA CORPORATION