Re: Support worker_spi to execute the function dynamically.
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Masahiro Ikeda <ikedamsh@oss.nttdata.com>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2023-07-20T03:55:43Z
Lists: pgsql-hackers
Attachments
- 0001-Add-tweak-to-allow-worker_spi-to-register-wait_event.patch (text/x-diff) patch 0001
On Thu, Jul 20, 2023 at 11:15:51AM +0900, Masahiro Ikeda wrote: > While I'm working on the thread[1], I found that the function of > worker_spi module fails if 'shared_preload_libraries' doesn't have > worker_spi. I guess that you were patching worker_spi to register dynamically a wait event and embed that in a TAP test or similar without loading it in shared_preload_libraries? FWIW, you could use a trick like what I am attaching here to load a wait event dynamically with the custom wait event API. You would need to make worker_spi_init_shmem() a bit more aggressive with an extra hook to reserve a shmem area size, but that's enough to show the custom wait event in the same backend as the one that launches a worker_spi dynamically, while demonstrating how the API can be used in this case. > In my understanding, the restriction is not required. So, I think it's > better to change the behavior. > (v1-0001-Support-worker_spi-to-execute-the-function-dynamical.patch) > > What do you think? +1. I'm OK to lift this restriction with a SIGHUP GUC for the database name and that's not a pattern to encourage in a template module. Will do so, if there are no objections. -- Michael
Commits
-
worker_spi: Fix race condition in newly-added TAP tests
- b68e356a680e 17.0 landed
-
worker_spi: Switch to TAP tests
- 320c311fda91 17.0 landed
-
worker_spi: Use term "dynamic" for bgworkers launched with worker_spi_launch()
- d9eb92c7b122 17.0 landed
-
Fix worker_spi when launching workers without shared_preload_libraries
- 97ff8dd02ca7 17.0 landed