Dear Michael,
> 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.
Okay, so this proposal has the advantage that we can terminate workers, even if the
extensions do not control workers on the shared memory, right?
> 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?
+1 to extend the bgw_flags.
Best regards,
Hayato Kuroda
FUJITSU LIMITED
