On Mon, Oct 06, 2025 at 01:59:08AM +0000, Hayato Kuroda (Fujitsu) wrote:
> Per my understanding, we already have a facility that terminates a background
> worker, TerminateBackgroundWorker(). So, I'm afraid your proposal has already
> been done by combining this function and ProcessUtility_hook.
The main take that I am getting here from Iwata-san is that this would
lead to less code duplication. Another item, which you are not
mentioning, is that this would be more flexible with bgworkers that
have been starting dynamically, where shared_preload_libraries may not
be used, still a bgworker would need to react. So the suggestion of a
new API to control if a bgworker should be stopped like any other
backend when there is a database activity worth it is a good one, as
long as it is in line with what we do with normal backends.
AcceptBackgroundWorkerCancel() is going backwards, IMO. Wouldn't it
be better to pass it down as an option in bgw_flags, to mark that a
bgworker connected to a database can be shutdown due to the effect of
a database getting dropped or moved? There could be an argument
behind using bgw_extra, but that would not be in line with the
database connection argument which is a state defined when a bgworker
is registered.
> So, is the main benefit of the patch to shorten extensions codes which uses
> bgworker?
I'd ask for the addition of tests when it comes to such a facility,
and your proposal has none of that. I would suggest worker_spi with
an option that can be passed to worker_spi_launch().
--
Michael
