Re: [PROPOSAL] Termination of Background Workers for ALTER/DROP DATABASE

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: [PROPOSAL] Termination of Background Workers for ALTER/DROP DATABASE
Дата
Msg-id CAFj8pRCn0=jn4yaeg1JoxxxnUNeXm1KCouES8Puq_GgBsXrNTQ@mail.gmail.com
обсуждение исходный текст
Ответ на RE: [PROPOSAL] Termination of Background Workers for ALTER/DROP DATABASE  ("Aya Iwata (Fujitsu)" <iwata.aya@fujitsu.com>)
Список pgsql-hackers
Hi

st 17. 12. 2025 v 14:31 odesílatel Aya Iwata (Fujitsu) <iwata.aya@fujitsu.com> napsal:
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).

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. 

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?

Regards

Pavel
 

Best Regards,
Aya Iwata

В списке pgsql-hackers по дате отправления: