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

Hello Parragi

Thank you for suggesting this improvement.

I agree that if the database remains after the command is executed,
the terminated bgworker should reconnect.

However, in the proposed implementation, the system would attempt to reconnect
multiple times even if the DROP operation succeeds. I think this point requires
further discussion.
If the `DROP DATABASE` command succeeds, almost all worker creators would likely
not want to reconnect. In that case, I believe this should be handled as a core
feature rather than left to an extension.

In the case of the DROP command, I think users would not want to reconnect to
the database regardless of whether it succeeds or fails. This is because I think
users whose DROP attempt failed would simply try the DROP command again.
If the database is going to be deleted anyway, they likely wouldn't want to reconnect.

On the other hand, in the case of ALTER DATABASE,
if the database ID does not change regardless of the command's result, it might
be useful for the bgworker to reconnect.

Regards,
Aya Iwata