Re: BGWORKER_INTERRUPTIBLE workers are never restarted after DROP/ALTER/CREATE DATABASE

On Fri, Nov 06, 2026 at 05:42:58AM -0800, Zsolt Parragi wrote:
> Yes, I agree that this part is questionable, but to me this still
> looks like the safest choice:
>
> 1. it can already be the case in other scenarios, so this is not
> really new behavior
> 2. can the core for sure make the assumption that the bgworker will
> want to reconnect to the same database again?

Hmm. The restart time is settable at will. It sounds like a problem
to me to not give this option to users, at least. I agree with
Iwata-san's point that in most cases, admins would just want to ditch
away interruptible workers. Howerver, I can buy the case of the
connection database being under an updatable GUC, where the GUC is
updated to a new database, until the restart time kicks in to connect
to a new database than the one originally manipulated (say a rename in
a maintenance window, whatever).

So it's a matter of options. Having one more option sounds like a
good thing to me. Or we could make the restart time change only on
HEAD. As this feature is not released yet, it's still more appealing
to just do the change and be done with it.
--
Michael