| From: | Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com> |
|---|---|
| To: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Michael Paquier <michael(at)paquier(dot)xyz> |
| Subject: | BGWORKER_INTERRUPTIBLE workers are never restarted after DROP/ALTER/CREATE DATABASE |
| Date: | 2026-11-05 23:20:32 |
| Message-ID: | CAN4CZFNP+_aVsTqxfyNLU+AtRZMJeDRAR9XRfjPTwsWs3TXVaQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
| Attachment | Content-Type | Size |
|---|---|---|
| v1-0001-Fix-restart-of-interruptible-bgworkers-after-data.patch | application/octet-stream | 8.0 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Baji Shaik | 2026-11-05 23:52:12 | Fix pg_dump of grouped large object ACLs granted by a non-owner |
| Previous Message | Peter Smith | 2026-11-05 23:05:13 | Re: pg_dump --exclude-table loses FOR ALL TABLES EXCEPT publications |