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
-
Change custom wait events to use dynamic shared hash tables
- af720b4c50a1 17.0 landed
-
Support custom wait events for wait event type "Extension"
- c9af05465307 17.0 landed
-
Add WAIT_EVENT_{CLASS,ID}_MASK in wait_event.c
- 7395a90db87b 17.0 landed
-
worker_spi: Switch to TAP tests
- 320c311fda91 17.0 cited
-
Simplify some conditions related to [LW]Lock in generate-wait_event_types.pl
- c17164aec88c 17.0 landed