From: Masahiro Ikeda <ikedamsh@oss.nttdata.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Andres Freund <andres@anarazel.de>
Cc: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Cc: Tristan Partin <tristan@neon.tech>
Cc: pgsql-hackers@lists.postgresql.org
Subject: Re: Support to define custom wait events for extensions
Date: Tue, 08 Aug 2023 09:39:02 +0900
Message-ID: <2373bd1fe4d0156649dc5794a86fe94e@oss.nttdata.com> (raw)
In-Reply-To: <ZNGEImKhwtgL2zlq@paquier.xyz>
References: <CALj2ACVq=BogP=iQ0C=Pjzk4+rSTaKZU_+fdMRk4YyG8B60gAQ@mail.gmail.com>
<ZMcJ7F7nkGkIs8zP@paquier.xyz>
<446d286f3272437df705ee69ad0d8793@oss.nttdata.com>
<ZMdikEm4Xq9KQKNY@paquier.xyz>
<CALj2ACW=Lourradi-Kb=hGFfdNxdejx3kOeUdToaUky+L3xKZw@mail.gmail.com>
<ZMeLe6ywYk+PMsDQ@paquier.xyz>
<171b38978ae8a21e5635998d9bfedbf6@oss.nttdata.com>
<ZMh4qaxwjNE80tmo@paquier.xyz>
<20230801032349.aaiuvhtrcvvcwzcx@awork3.anarazel.de>
<9cc4136f9e3629a2ffc8ac66b4de3f31@oss.nttdata.com>
<ZNGEImKhwtgL2zlq@paquier.xyz>
On 2023-08-08 08:54, Michael Paquier wrote:
> On Wed, Aug 02, 2023 at 06:34:15PM +0900, Masahiro Ikeda wrote:
>> On 2023-08-01 12:23, Andres Freund wrote:
>>> This is why the scheme as implemented doesn't really make sense to
>>> me.
>>> It'd be
>>> much easier to use if we had a shared hashtable with the identifiers
>>> than
>>> what's been merged now.
>>>
>>> In plenty of cases it's not realistic for an extension library to run
>>> in
>>> each
>>> backend, while still needing to wait for things.
>>
>> OK, I'll try to make a PoC patch.
>
> Hmm. There are a few things to take into account here:
> - WaitEventExtensionShmemInit() should gain a dshash_create(), to make
> sure that the shared table is around, and we are going to have a
> reference to it in WaitEventExtensionCounterData, saved from
> dshash_get_hash_table_handle().
> - The hash table entries could just use nextId as key to look at the
> entries, with entries added during WaitEventExtensionNew(), and use as
> contents the name of the wait event. We are going to need a fixed
> size for these custom strings, but perhaps a hard limit of 256
> characters for each entry of the hash table is more than enough for
> most users?
> - WaitEventExtensionRegisterName() could be removed, I guess, replaced
> by a single WaitEventExtensionNew(), as of:
> uint32 WaitEventExtensionNew(const char *event_name);
> - GetWaitEventExtensionIdentifier() needs to switch to a lookup of the
> shared hash table, based on the eventId.
>
> All that would save from the extra WaitEventExtensionRegisterName()
> needed in the backends to keep a track of the names, indeed.
Thank you for pointing the direction of implementation.
I am thinking a bit that we also need another hash where the key
is a custom string. For extensions that have no dependencies
with shared_preload_libraries, I think we need to avoid that
WaitEventExtensionNew() is called repeatedly and a new eventId
is issued each time.
So, is it better to have another hash where the key is
a custom string and uniqueness is identified by it to determine
if a new eventId should be issued?
Regards,
--
Masahiro Ikeda
NTT DATA CORPORATION
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: ikedamsh@oss.nttdata.com, michael@paquier.xyz, andres@anarazel.de, bharath.rupireddyforpostgres@gmail.com, tristan@neon.tech, pgsql-hackers@lists.postgresql.org
Subject: Re: Support to define custom wait events for extensions
In-Reply-To: <2373bd1fe4d0156649dc5794a86fe94e@oss.nttdata.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox