Re: Support worker_spi to execute the function dynamically.

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Masahiro Ikeda <ikedamsh(at)oss(dot)nttdata(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Support worker_spi to execute the function dynamically.
Date: 2023-07-20 03:55:43
Message-ID: ZLiwP5vrT/SENzim@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Attachment Content-Type Size
0001-Add-tweak-to-allow-worker_spi-to-register-wait_event.patch text/x-diff 2.5 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2023-07-20 03:59:41 Re: [PATCH] Reuse Workers and Replication Slots during Logical Replication
Previous Message Gurjeet Singh 2023-07-20 03:45:41 Re: Issue in _bt_getrootheight