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
