Hi Pavel-san Thank you for your feedback!
> From: Pavel Stehule <[email protected]> > Sent: Thursday, December 18, 2025 12:33 AM > To: Iwata, Aya/岩田 彩 <[email protected]> > Cc: Michael Paquier <[email protected]>; Peter Smith > <[email protected]>; Chao Li <[email protected]>; Kuroda, Hayato/黒田 > 隼人 <[email protected]>; pgsql-hackers <[email protected]> > Subject: Re: [PROPOSAL] Termination of Background Workers for ALTER/DROP > DATABASE >> Hi Pavel-san, >> >> >> So maybe there should be ALTER DATABASE ... RENAME ... FORCE - or if >> >> FORCE can terminare all workers (without special FLAG) ? >> > >> > For the proposed feature, we've added a flag allowing each extension >> > developer to decide whether to terminate it via DROP/ALTER DATABASE. >> > Adding a FORCE option to ALTER to let database definition modifiers decide >> > whether to force termination of background workers might be better >> > discussed in a separate thread. >> > >> > When I thought about it - there can be a second alternative. >> > >> > Introduce a pair of flags BGWORKER_INTERRUPTABLE and BGWORKER_PROTECTED >> > (the names can be enhanced or changed). BGWORKER_INTERRUPTABLE can be >> > default. >> > ALTER DATABASE RENAME and related commands can stop any non protected >> > workers. ALTER DATABASE RENAME FORCE can stop any workers (including >> > protected). >> >> I can't image any use cases for BGWORKER_PROTECTED. Do you have any idea? >> Also, I think the parameter settings might get a complicated. >> If we start discussing the "FORCE" option, it is better to think about this >> parameter. >> >> > Is there any reason why BGWORKER_INTERRUPTABLE cannot be default? Probably >> > nobody would block some possibly common operations on database level >> > without strong reason. >> >> As Michael-san mentioned in a previous email, this behavior has remained >> unchanged since bgworkers were introduced in v9.3. >> I don't see a compelling reason to alter it now. Additionally, this >> specification can be modified later. > I understand the request for unchanging behaviour - but I am not sure if this > concept is really helpful - or if the naming is best. I am afraid so this > feature without changing the workers code is useless (and maybe it is wanted). It is our intention; this feature would enable when developer expressly set. > Any worker should be interruptable by sigterm. And then the name > BGWORKER_INTERRUPTABLE is little bit vague. Maybe some like > BGWORKER_CAREFREE_INTERRUPTABLE can be better (or some like this - maybe > BGWORKER_CANCELABLE)? This can be a signal from bgworker's authors - it is ok > to kill the worker anytime when it is necessary. That's right, "interruptable" may not be appropriate. This is because even bgworkers without this flag set can be interrupted by sigterm. Hmm, I feel these ideas may not be clear what it does. Do someone have other idea? > Some workers can have the flag BGW_NEVER_RESTART - cannot be used as signal > so this worker is protected, and others can be terminated safely, because > they will be restarted after 60 seconds? In my understanding, you are suggesting that the bgworker which set bgw_restart_time as BGW_NEVER_RESTART is not terminated by DROP/ALTER, right? Do you think what kind of use cases might there be? Best Regards, Aya Iwata
