MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Date: Wed, 02 Aug 2023 18:34:15 +0900
From: Masahiro Ikeda <ikedamsh@oss.nttdata.com>
To: Andres Freund <andres@anarazel.de>
Cc: Michael Paquier <michael@paquier.xyz>, Bharath Rupireddy
 <bharath.rupireddyforpostgres@gmail.com>, Tristan Partin
 <tristan@neon.tech>, pgsql-hackers@lists.postgresql.org
Subject: Re: Support to define custom wait events for extensions
In-Reply-To: <20230801032349.aaiuvhtrcvvcwzcx@awork3.anarazel.de>
References: <cd09c86daa9e4c1c5f7903da39b75994@oss.nttdata.com>
 <ZMMUiR7kvzPWenhF@paquier.xyz>
 <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>
User-Agent: Roundcube Webmail/1.4.11
Message-ID: <9cc4136f9e3629a2ffc8ac66b4de3f31@oss.nttdata.com>
Archived-At: 
 <https://www.postgresql.org/message-id/9cc4136f9e3629a2ffc8ac66b4de3f31%40oss.nttdata.com>
Precedence: bulk

On 2023-08-01 12:23, Andres Freund wrote:
> Hi,
> 
> On 2023-08-01 12:14:49 +0900, Michael Paquier wrote:
>> On Tue, Aug 01, 2023 at 11:51:35AM +0900, Masahiro Ikeda wrote:
>> > Thanks for committing the main patch.
>> >
>> > In my understanding, the rest works are
>> > * to support WaitEventExtensionMultiple()
>> > * to replace WAIT_EVENT_EXTENSION to custom wait events
>> >
>> > Do someone already works for them? If not, I'll consider
>> > how to realize them.
>> 
>> Note that postgres_fdw and dblink use WAIT_EVENT_EXTENSION, but have
>> no dependency to shared_preload_libraries.  Perhaps these could just
>> use a dynamic handling but that deserves a separate discussion because
>> of the fact that they'd need shared memory without being able to
>> request it.  autoprewarm.c is much simpler.
> 
> 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.

Regards,
-- 
Masahiro Ikeda
NTT DATA CORPORATION