Re: Support to define custom wait events for extensions - Mailing list pgsql-hackers

From Masahiro Ikeda
Subject Re: Support to define custom wait events for extensions
Date
Msg-id 9cc4136f9e3629a2ffc8ac66b4de3f31@oss.nttdata.com
Whole thread Raw
In response to Re: Support to define custom wait events for extensions  (Andres Freund <andres@anarazel.de>)
Responses Re: Support to define custom wait events for extensions
List 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



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: multiple membership grants and information_schema.applicable_roles
Next
From: Melih Mutlu
Date:
Subject: Re: [PATCH] Reuse Workers and Replication Slots during Logical Replication