Re: Support to define custom wait events for extensions
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Michael Paquier <michael@paquier.xyz>
Cc: Masahiro Ikeda <ikedamsh@oss.nttdata.com>, Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>, Tristan Partin <tristan@neon.tech>, pgsql-hackers@lists.postgresql.org
Date: 2023-08-01T03:23:49Z
Lists: pgsql-hackers
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. Greetings, Andres Freund
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