Hello "Allow bgworkers to be terminated for database-related commands" added BGWORKER_INTERRUPTIBLE: for DROP/ALTER/CREATE DATABASE the postmaster terminates the background worker... and then forgets about it, even ignoring bgw_restart_time. So a static worker from shared_preload_libraries, or a dynamic one with a restart time is gone until the next postmaster restart.
This also happens when the command itself fails. With a static interruptible worker (bgw_restart_time = 1) connected to db1, and a regular session also connected to db1: DROP DATABASE db1; ERROR: database "db1" is being accessed by other users DETAIL: There is 1 other session using the database. db1 still exists, but its worker never comes back. Same for ALTER DATABASE and CREATE DATABASE ... TEMPLATE. pg_terminate_backend() on the same worker do get it restarted after 1s. The attached patch adds an "interrupt" flag to BackgroundWorkerSlot next to "terminate", so the postmaster only kills them once and then restarts them later. With this, after a successful DROP DATABASE a restartable worker now comes back and keeps failing to connect to the dropped database every bgw_restart_time. That is the same as what happens to a non-interruptible worker whose database disappears, and the extension can handle it.
v1-0001-Fix-restart-of-interruptible-bgworkers-after-data.patch
Description: Binary data
