MIME-Version: 1.0
References: <aOctHMnSZcREh0BR@paquier.xyz>
 <OSCPR01MB1496614832F8014EC16FB78D2F5EEA@OSCPR01MB14966.jpnprd01.prod.outlook.com>
 <aOc7_JGErxvqBLMP@paquier.xyz>
 <OSCPR01MB14966EC12277712131EB8EDF1F5EEA@OSCPR01MB14966.jpnprd01.prod.outlook.com>
 <OS7PR01MB11964C8FE9CDCC0F4C9110988EAEEA@OS7PR01MB11964.jpnprd01.prod.outlook.com>
 <E8C35CCE-E92F-467B-A604-5C1BBBA8F1C8@gmail.com>
 <OS7PR01MB11964C077A3E61F4887DD3D09EAEFA@OS7PR01MB11964.jpnprd01.prod.outlook.com>
 <CAHut+PtbOP_80OPZXCUZO=-pBJSRTmHcQ2MnVTFov1meNbw18Q@mail.gmail.com>
 <CAHut+Pt5BN0LDh7OzbNqh9+zqHBgsrLX+vh-gn+3FKYTFHMvhw@mail.gmail.com>
 <TY3PR01MB11969CBD6DF3E0DB820AD4262EAE8A@TY3PR01MB11969.jpnprd01.prod.outlook.com>
 <aPBsd2e2SqLs0Kdk@paquier.xyz>
 <CAFj8pRB_FH-Pcth9XFcpY2OTasVOP-2DfYOsVxL38igw0O4hdg@mail.gmail.com>
 <OS7PR01MB119647141272DBF9364A1C5AAEAADA@OS7PR01MB11964.jpnprd01.prod.outlook.com>
 <CAFj8pRCRnN4SyZDPbQwTyKZ_kVHfwLG6udCXsXDTG_z9fWwYQg@mail.gmail.com>
 <OS7PR01MB119648203BD748ED008FA5BF5EAABA@OS7PR01MB11964.jpnprd01.prod.outlook.com>
In-Reply-To: 
 <OS7PR01MB119648203BD748ED008FA5BF5EAABA@OS7PR01MB11964.jpnprd01.prod.outlook.com>
From: Pavel Stehule <pavel.stehule@gmail.com>
Date: Wed, 17 Dec 2025 16:33:16 +0100
Message-ID: 
 <CAFj8pRCn0=jn4yaeg1JoxxxnUNeXm1KCouES8Puq_GgBsXrNTQ@mail.gmail.com>
Subject: Re: [PROPOSAL] Termination of Background Workers for ALTER/DROP
 DATABASE
To: "Aya Iwata (Fujitsu)" <iwata.aya@fujitsu.com>
Cc: Michael Paquier <michael@paquier.xyz>,
 Peter Smith <smithpb2250@gmail.com>,
	Chao Li <li.evan.chao@gmail.com>,
	"Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>,
 pgsql-hackers <pgsql-hackers@postgresql.org>
Content-Type: multipart/alternative; boundary="00000000000055102a0646279267"
Archived-At: 
 <https://www.postgresql.org/message-id/CAFj8pRCn0%3Djn4yaeg1JoxxxnUNeXm1KCouES8Puq_GgBsXrNTQ%40mail.gmail.com>
Precedence: bulk

--00000000000055102a0646279267
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi

st 17. 12. 2025 v 14:31 odes=C3=ADlatel 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
>

--00000000000055102a0646279267
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi</div><br><div class=3D"gmail_quote gmail_quote_con=
tainer"><div dir=3D"ltr" class=3D"gmail_attr">st 17. 12. 2025 v=C2=A014:31 =
odes=C3=ADlatel Aya Iwata (Fujitsu) &lt;<a href=3D"mailto:iwata.aya@fujitsu=
.com">iwata.aya@fujitsu.com</a>&gt; napsal:<br></div><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204=
,204,204);padding-left:1ex">Hi Pavel-san,<br>
<br>
&gt;&gt; So maybe there should be ALTER DATABASE ... RENAME ... FORCE - or =
if FORCE can terminare all workers (without special FLAG) ?<br>
&gt; <br>
&gt; For the proposed feature, we&#39;ve added a flag allowing each extensi=
on developer to decide whether to terminate it via DROP/ALTER DATABASE.<br>
&gt; Adding a FORCE option to ALTER to let database definition modifiers de=
cide whether to force termination of background workers might be better dis=
cussed in a separate thread.<br>
&gt; <br>
&gt; When I thought about it - there can be a second alternative.<br>
&gt; <br>
&gt; Introduce a pair of flags BGWORKER_INTERRUPTABLE and BGWORKER_PROTECTE=
D (the names can be enhanced or changed). BGWORKER_INTERRUPTABLE can be def=
ault. <br>
&gt; ALTER DATABASE RENAME and related commands can stop any non protected =
workers. ALTER DATABASE RENAME FORCE can stop any workers (including protec=
ted). <br>
<br>
I can&#39;t image any use cases for BGWORKER_PROTECTED. Do you have any ide=
a?<br>
Also, I think the parameter settings might get a complicated.<br>
If we start discussing the &quot;FORCE&quot; option, it is better to think =
about this parameter.<br>
<br>
&gt; Is there any reason why BGWORKER_INTERRUPTABLE cannot be default? Prob=
ably nobody would block some possibly common operations on database level w=
ithout strong reason.<br>
<br>
As Michael-san mentioned in a previous email, this behavior has remained un=
changed since bgworkers were introduced in v9.3. <br>
I don&#39;t see a compelling reason to alter it now.=C2=A0 Additionally, th=
is specification can be modified later.<br></blockquote><div><br></div><div=
>I understand the request for unchanging behaviour - but I am not sure if t=
his concept is really helpful - or if the naming is best. I am afraid so th=
is feature without changing the workers code is useless (and maybe it is wa=
nted).</div><div><br></div><div>Any worker should be=C2=A0interruptable=C2=
=A0by sigterm. And then the name=C2=A0BGWORKER_INTERRUPTABLE is little bit =
vague. Maybe some like=C2=A0BGWORKER_CAREFREE_INTERRUPTABLE can be better (=
or some like this - maybe BGWORKER_CANCELABLE)? This can be a signal from b=
gworker&#39;s authors - it is ok to kill the=C2=A0worker anytime when it is=
 necessary.=C2=A0</div><div><br></div><div>Some workers can have the flag B=
GW_NEVER_RESTART - cannot be used as signal so this worker is protected, an=
d others can be terminated safely, because they will be restarted after 60 =
seconds?</div><div><br></div><div>Regards</div><div><br></div><div>Pavel</d=
iv><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Best Regards,<br>
Aya Iwata<br>
</blockquote></div></div>

--00000000000055102a0646279267--