Re: Support to define custom wait events for extensions

Masahiro Ikeda <ikedamsh@oss.nttdata.com>

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
Date: 2023-08-02T09:34:15Z
Lists: pgsql-hackers
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



Commits

  1. Change custom wait events to use dynamic shared hash tables

  2. Support custom wait events for wait event type "Extension"

  3. Add WAIT_EVENT_{CLASS,ID}_MASK in wait_event.c

  4. worker_spi: Switch to TAP tests

  5. Simplify some conditions related to [LW]Lock in generate-wait_event_types.pl