Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vWGVT-00GG3R-2d for pgsql-hackers@arkaria.postgresql.org; Thu, 18 Dec 2025 16:05:36 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vWGVQ-002suT-0p for pgsql-hackers@arkaria.postgresql.org; Thu, 18 Dec 2025 16:05:33 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vWGVP-002suL-2x for pgsql-hackers@lists.postgresql.org; Thu, 18 Dec 2025 16:05:32 +0000 Received: from mail-yx1-xb132.google.com ([2607:f8b0:4864:20::b132]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vWGVN-001RJo-2X for pgsql-hackers@postgresql.org; Thu, 18 Dec 2025 16:05:32 +0000 Received: by mail-yx1-xb132.google.com with SMTP id 956f58d0204a3-6432842cafdso698996d50.2 for ; Thu, 18 Dec 2025 08:05:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1766073928; x=1766678728; darn=postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=1W5Ft/Z5wg2X9wIDug33I0I6NNFdjm2KFrFxCLRzLfg=; b=Bxy58Jbrg4KqeVW3xvj7PTPNXCUN4DZoGlRrpZ30bGfWJ+fUpfUWkA/Mv7cCjS7J7L nY4UH+nPaAe3wJgBmBISON98w0bFMR3ypf0jsEqHyZH350JPCkcEpWFD0huUyLNFkRFP QTzYi8v6AKyH6FVJbUP/2j6gOHqyu8TeaSQJQZhc9zhVgF4cAcLZL77S0mJJ3FHl4bfP mY+9egBSSrad2V1i81PnKF/UOgPRq65V6O6GkNMYvTBA+GBWJTkc81pDe9Qw/OggkUcl FzsO10IpS9AFoUoIAhIb8WlJG+vUKkVs6fpeExCNadAaIyHCDNZOSOvxEX58jLIXBb44 6aLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1766073928; x=1766678728; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=1W5Ft/Z5wg2X9wIDug33I0I6NNFdjm2KFrFxCLRzLfg=; b=KrS3z0RhpVc1DJAb2gA/0HmvDSTPWQxLzhFfc3A48t71oZRDKUh/1inbpdgfvnGJHq BzmDP7iL5uS+i15HFiCyd7VKIf10H2lsHdR8jv45d7VbhE6Vm7w3tW3tYWHVr+S3yybE 8XLCha77cucPKO3ZzYTzselKv7dVgZyx1+oex0hMU+U9tOvbzsz6pj0WU5NhOkPJq9iG KVueJmsgVv54l02DzBpDwITLPf0VMOEu7wgE7MEyDVoNWz41hBDKKgzIwDH0MvwP4Nz5 Ap3sB0xT9/KJVBgV4AC0CQLwBPup6LXQzm7T3BSJAjD0ixGlUgHnZCBq+yAndfKIX5dP MOyQ== X-Forwarded-Encrypted: i=1; AJvYcCUru6qJyRS/YupnqpqvUQ9FBBfKpQBIpdPCypVApf8ERSaa4siN/5ayLtkwZyA5+zz8YZPOyFKpDjQ1vjlY@postgresql.org X-Gm-Message-State: AOJu0YzgVRUNjcY4y1AZXkWnrxv8EyCQiCQJw4eLbpQq7LXZ8NxPJSSD ZxaonmSUa2u4B7gNSp+MuRgPjh/85La3CgOkNsdWfAiG3MkSu1iYLi7IC1zaLUMG2zjWiAHyKq+ 4UtpWIY7lkgXXlmBR3B6cm64aPq3ofLQ= X-Gm-Gg: AY/fxX7nYN9EWbiJJhkrdsxkJD2gQE8ZxlLPSX1u2K+MVPwnpveHObpXqvlaxE7Mg4r o7gOWLAoYndpYE9HWoQfZevXIZbMpy+Hc7AKjr/sZnrcjs16cf9jxgn4NUWAKzYxrq2WmMXsQqG nHlGO1dF7j8eIqPIXzp9meE6YRfR6j65thZooXf5/ODDTfuRF7X30cODfwYc6G5JdvygwJsK9SD V6fAEgwd+wT24L0Lb4z+ugOg2P4bcIVRn4UF8AGyNvPqPdtBiJyxB1dzPdmOr60XdROCnYrNVfY cFKz4ygv61/PZPKMOR15o4Ps+EKJf282GRoZBusa9Q2GrgONxJxucgafXRIcaevRk+h9c/cdr6n 5K/wqNnGwSoMhzQ== X-Google-Smtp-Source: AGHT+IG6UGrMhwC05PUflwGQ1ot67hBjxZucFmfNxFKQplESdO1PY1YwmQ/psr5AlMVGUUQbBbipJpJtiPPs4UWV2NE= X-Received: by 2002:a05:690e:4144:b0:645:5540:2cd3 with SMTP id 956f58d0204a3-645555d2663mr17541160d50.3.1766073927731; Thu, 18 Dec 2025 08:05:27 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Pavel Stehule Date: Thu, 18 Dec 2025 17:04:50 +0100 X-Gm-Features: AQt7F2qY_Mtrim0w3Mc8mYYRCt7_OaGSiN-_zG4de0IpKFAVrREMxFBvqB9bhdo Message-ID: Subject: Re: [PROPOSAL] Termination of Background Workers for ALTER/DROP DATABASE To: "Aya Iwata (Fujitsu)" Cc: Michael Paquier , Peter Smith , Chao Li , "Hayato Kuroda (Fujitsu)" , pgsql-hackers Content-Type: multipart/alternative; boundary="0000000000001c0fb406463c21e6" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000001c0fb406463c21e6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =C4=8Dt 18. 12. 2025 v 12:47 odes=C3=ADlatel Aya Iwata (Fujitsu) < iwata.aya@fujitsu.com> napsal: > Hi Pavel-san > > Thank you for your feedback! > > > From: Pavel Stehule > > Sent: Thursday, December 18, 2025 12:33 AM > > To: Iwata, Aya/=E5=B2=A9=E7=94=B0 =E5=BD=A9 > > Cc: Michael Paquier ; Peter Smith < > smithpb2250@gmail.com>; Chao Li ; Kuroda, > Hayato/=E9=BB=92=E7=94=B0 =E9=9A=BC=E4=BA=BA ;= pgsql-hackers < > pgsql-hackers@postgresql.org> > > Subject: Re: [PROPOSAL] Termination of Background Workers for ALTER/DRO= P > DATABASE > >> Hi Pavel-san, > >> > >> >> So maybe there should be ALTER DATABASE ... RENAME ... FORCE - or i= f > 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 protecte= d > 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 i= f > 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 i= s > 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 i= s > ok to kill the worker anytime when it is necessary. > > That's right, "interruptable" may not be appropriate. This is because eve= n > 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? > I don't think about use cases - just workers that can be restarted can be terminated with less risk than workers that shouldn't be restarted - and maybe BGWORKER_CAREFREE_INTERRUPTABLE is just negation of BGW_NEVER_RESTART in almost cases. I afraid so BGWORKER_CAREFREE_INTERRUPTABLE (or maybe BGWORKER_SAFELY_INTERRUPTABLE) will be source of bugs - this flag is just "safeguard" for very special cases - and very common bug will be omission of this flug until someone reports (after long time) "it block database rename". Second objection against this design is inconsistency with current CREATE, DROP DATABASE commands. Without the FORCE flag, it terminates nothing. And with the FORCE flag it terminates anything that is necessary. Proposed design is safe - because only specially marked bgworkers are terminated, but for users it can be unwanted surprise still - and at the end in next versions - mostly bgworkers will have this flag, because nobody want to block DDL Regards Pavel > Best Regards, > Aya Iwata > --0000000000001c0fb406463c21e6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=C4=8Dt 18. 12.= 2025 v=C2=A012:47 odes=C3=ADlatel Aya Iwata (Fujitsu) <iwata.aya@fujitsu.com> napsal:
Hi Pavel-san

Thank you for your feedback!

> From: Pavel Stehule <pavel.stehule@gmail.com>
> Sent: Thursday, December 18, 2025 12:33 AM
> To: Iwata, Aya/=E5=B2=A9=E7=94=B0 =E5=BD=A9 <iwata.aya@fujitsu.com>
> Cc: Michael Paquier <michael@paquier.xyz>; Peter Smith <smithpb2250@gmail.com>; Cha= o Li <li.eva= n.chao@gmail.com>; Kuroda, Hayato/=E9=BB=92=E7=94=B0 =E9=9A=BC=E4=BA= =BA <kuro= da.hayato@fujitsu.com>; pgsql-hackers <pgsql-hackers@postgresql.org>= ;
> Subject: Re: [PROPOSAL] Termination of Background Workers for ALTER/DR= OP DATABASE
>> Hi Pavel-san,
>>
>> >> So maybe there should be ALTER DATABASE ... RENAME ... FO= RCE - or if FORCE can terminare all workers (without special FLAG) ?
>> >
>> > For the proposed feature, we've added a flag allowing eac= h extension developer to decide whether to terminate it via DROP/ALTER DATA= BASE.
>> > Adding a FORCE option to ALTER to let database definition mod= ifiers decide whether to force termination of background workers might be b= etter discussed in a separate thread.
>> >
>> > When I thought about it - there can be a second alternative.<= br> >> >
>> > Introduce a pair of flags BGWORKER_INTERRUPTABLE and BGWORKER= _PROTECTED (the names can be enhanced or changed). BGWORKER_INTERRUPTABLE c= an be default.
>> > ALTER DATABASE RENAME and related commands can stop any non p= rotected workers. ALTER DATABASE RENAME FORCE can stop any workers (includi= ng protected).
>>
>> I can't image any use cases for BGWORKER_PROTECTED. Do you hav= e 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 defa= ult? Probably nobody would block some possibly common operations on databas= e level without strong reason.
>>
>> As Michael-san mentioned in a previous email, this behavior has re= mained 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 s= o this feature without changing the workers code is useless (and maybe it i= s wanted).

It is our intention; this feature would enable when developer expressly set= .

> Any worker should be interruptable by sigterm. And then the name BGWOR= KER_INTERRUPTABLE is little bit vague. Maybe some like BGWORKER_CAREFREE_IN= TERRUPTABLE 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 wor= ker 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 othe= r idea?

> Some workers can have the flag BGW_NEVER_RESTART - cannot be used as s= ignal so this worker is protected, and others can be terminated safely, bec= ause they will be restarted after 60 seconds?

In my understanding, you are suggesting that the bgworker which set bgw_res= tart_time as BGW_NEVER_RESTART is not terminated by DROP/ALTER, right?
Do you think what kind of use cases might there be?
I don't think about use cases - just workers that can be r= estarted can be terminated with less=C2=A0 risk than workers that shouldn&#= 39;t be restarted - and maybe=C2=A0BGWORKER_CAREFREE_INTERRUPTABLE is just = negation of BGW_NEVER_RESTART in almost cases.

I a= fraid so=C2=A0BGWORKER_CAREFREE_INTERRUPTABLE (or maybe=C2=A0BGWORKER_SAFEL= Y_INTERRUPTABLE) will be source of bugs - this flag is just "safeguard= " for very special cases - and very common bug will be omission of thi= s flug until someone reports (after long time) "it block database rena= me".

Second objection against this design is = inconsistency with current CREATE, DROP DATABASE commands. Without the FORC= E flag, it terminates nothing. And with the FORCE flag it terminates anythi= ng that is necessary. Proposed design is safe - because only specially mark= ed bgworkers are terminated, but for users it can be unwanted surprise stil= l - and at the end in next versions - mostly bgworkers=C2=A0will have this = flag, because nobody want to block DDL

Regards

Pavel



Best Regards,
Aya Iwata
--0000000000001c0fb406463c21e6--