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 1vZ5dR-0032Il-2a for pgsql-hackers@arkaria.postgresql.org; Fri, 26 Dec 2025 11:05:30 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vZ5dQ-009FmX-1S for pgsql-hackers@arkaria.postgresql.org; Fri, 26 Dec 2025 11:05:29 +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 1vZ5dQ-009FmO-0L for pgsql-hackers@lists.postgresql.org; Fri, 26 Dec 2025 11:05:28 +0000 Received: from mail-yx1-xb136.google.com ([2607:f8b0:4864:20::b136]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vZ5dO-002uzP-0H for pgsql-hackers@postgresql.org; Fri, 26 Dec 2025 11:05:28 +0000 Received: by mail-yx1-xb136.google.com with SMTP id 956f58d0204a3-6420c08f886so8969608d50.3 for ; Fri, 26 Dec 2025 03:05:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1766747124; x=1767351924; 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=KBpzTs2zEeM1oxr8iQsv+KSKyeNf206cojpRUycJCug=; b=eIGAeM25XzwGS26uUm9xms7MTa2vFtAFRfNwhnmqudF+58tIoSlCkedRdf++MLmD7h aEdzBnhmTqN/KJChOGStx7VOeVeCCQZ7gbvc59U53lnZnx78UsRBYEsnh8a4431lueoV V8fIJl9P21osmJGa+PYcXQ4HmKMXl/oNR4R6ql1V11y4gn+6WAyT0gl68jg+cgqn9IEN 5R1JTwp/oFSqQtSX7Qv4uY8niEr2e4YqrOgFCo4WUjWmWsFS7B3MIEKdeinWU4R9IJ6a pU9kzV21kmZonl/HazBx87wdh5PstNcEy9zwWv6b/dYbnAz4U4ixR9pRF35cjAat2AoM mP0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1766747124; x=1767351924; 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=KBpzTs2zEeM1oxr8iQsv+KSKyeNf206cojpRUycJCug=; b=Dp8umqKHmandefW1No2ucLZN0Z4UCgAszmM/cqPsB1m7i0OEecR8yoXHgfGqfdBKpU uWZrXoPzkb8AoUQm279hgqX5dawXBiI3ajpNzef1c5OveCavcjLXhspQKV3KGj3QRSfD nUB1dcU0FMsplBS+H5/aHMjnnRFBb5Ys2XqH8o8+kM89fzyc5FxYOeVE7/olCuLTe0zn 0T0lsW4VOg3Y+9IiR/cVtVKidcipG859o1Jb95SsIzx05tMDc5hQl6tia0zYA8/Jbuz2 trgBeinp7wyT/vJCyZt2v63lI4spM3d4EnJNyvQKFT8yT29f/tTT9KlfisjXgZMJ2qT0 ftrA== X-Forwarded-Encrypted: i=1; AJvYcCWYBnin1haZLc6H8yKfVq0tgkGRvbaJncF4vLpcolZqcutLNX8hCKhISl3DRHxSM1e5eiI4iLXZOri4sjqD@postgresql.org X-Gm-Message-State: AOJu0Yx/kFCuorMk7jQrF9bBHVYF2hoHQ7hx+2TS0o3hMHQANp9qxTwj gDUaZ5fJUyHmODbTqlLtC9CjRW2i6Sp1hyP6hfvES+11G2Xtu1D/vaAlihB7o0mg5X8bv0M1f8p VZrru4sVafCtCZWOzZ+ynbbG4e3cN+6I= X-Gm-Gg: AY/fxX7YVqozx6qSCpV6G+Z1NHJp6qve0DjLPSNDqx4YGFHAwLOKnZEVPKnhcMsZHhQ hQqYg+MeQkwm7eb6KKaKGnwN+xgA7sMEnKIJgSzIN2G85xTatQlJVZU/QTbTA5g9654rVqlkOXy qhy0kiqhePmr6WSEq8GYxDXyyNPCiJObORX8V8s7HX8LCmQLzK6nvneg8uHvVkHYyjM4i6U2nZG nuan7Wt3n0MC2DqSh3cmygweBY+dqnl/cpWh0rlEg2vkwFnAWPnGNMoK87KyqaQ3IItjMHnP/p2 1Vg92L+H5aZVMeip++cUe8YQAyJjDt1b902dmRryimzocJ7b+CvSifJKVMlG5w/h2TkamHN/iRW njhBUI/aw8bXLIg== X-Google-Smtp-Source: AGHT+IEYiCLKrgwzbexHlhiAEUQJShbKIMd8qYWLGUrIzNWx1OeRLctENyGPtHvJdKyZrz76JgKAaOI2lS69I1pPlzo= X-Received: by 2002:a53:c543:0:b0:645:5d39:2543 with SMTP id 956f58d0204a3-6466a84440cmr13637131d50.19.1766747123888; Fri, 26 Dec 2025 03:05:23 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Pavel Stehule Date: Fri, 26 Dec 2025 12:04:47 +0100 X-Gm-Features: AQt7F2rqvzxL1UB1ewQ0D8TbLi-CbeXhENyqtCRvvHhwXMqq4pJ-1s0Pm86Sc0k Message-ID: Subject: Re: [PROPOSAL] Termination of Background Workers for ALTER/DROP DATABASE To: "Ryo Matsumura (Fujitsu)" Cc: "Aya Iwata (Fujitsu)" , Michael Paquier , Peter Smith , Chao Li , "Hayato Kuroda (Fujitsu)" , pgsql-hackers Content-Type: multipart/alternative; boundary="000000000000ba34df0646d8de96" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000ba34df0646d8de96 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi p=C3=A1 26. 12. 2025 v 11:17 odes=C3=ADlatel Ryo Matsumura (Fujitsu) < matsumura.ryo@fujitsu.com> napsal: > Hi Pavel-san, Iwata-san, > > +1 to Allow-background-workers-to-be-terminated > > The result is same, so I think it's better to prioritize compatibility. > > PGWORKER_PROTECTED would be used in scenarios like the following: > Existing features are probably not designed to be forcibly stopped. > Therefore, all existing features should have PROTECTED applied to them. > Most newly implemented features will also have PROTECTED applied because > it requires less thought and is safer. > Only considerate developers of features that can easily guarantee safety > would adopt the default. > > In conclusion, this is no different from BGWORKER_INTERRUPTABLE. > Therefore, I think it's better to prioritize compatibility. > I am not sure if I understand what you prefer. I share your opinion that most developers use options that are more safe and require less thinking (and if this option will not be default, most developers maybe don't use it in the first cycle). At the end most bgworkers will be not be marked as interruptible (isn't important if we use flag INTERRUPTIBLE or PROTECTED). Then proposed flag without FORCE clause will be mostly inefficient - and then there is strong question if proposed feature has some real benefit. I don't think so this feature should be implemented and committed once, but we should to find a consensus on implemented behaviour in all possible cases, and all possible question. 1. When bgworker is marked as INTERRUPTIBLE, then can be cancelled immediately - there is full agreement - I don't see any problem - just probably almost all bgworkers will be not be marked as INTERRUPTIBLE 2. When bgworker is not marked as INTERRUPTIBLE, then can it be cancelled? How dangerous is this? If it cannot be cancelled, then ALTER should wait on lock forever, or there should be some special timeout - like CREATE, DROP DATABASE and waiting on template databases. 3. If the user needs to execute ALTER, then probably he manually terminates the worker any time. Are currently used workers safe against terminating? We know so mostly workers will be restarted after timeout - and then it is "safe". It is really safe? Can we expect it? If it is safe, then we can implement FORCE clause. Probably any worker can be restarted - and without safety it is hard to imagine using in the production. I think there is a fundamental question that should be solved before - what is a risk of canceling bgworker? The possible reply is so there is not any risk for correctly implemented bgworkers. And then there is a question if we still need the flag INTERRUPTIBLE? My opinion for this case is probably yes, because cancelling can introduce some bigger latency. Regards Pavel > > Best Regards > Ryo Matsumura > --000000000000ba34df0646d8de96 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi

p=C3=A1 26. 12. 2025 v=C2=A01= 1:17 odes=C3=ADlatel Ryo Matsumura (Fujitsu) <matsumura.ryo@fujitsu.com> napsal:
Hi Pavel-san, Iwata-san,=C2=A0

+1 to Allow-background-workers-to-be-terminated

The result is same, so I think it's better to prioritize compatibility.= =C2=A0

PGWORKER_PROTECTED would be used in scenarios like the following:
Existing features are probably not designed to be forcibly stopped.
Therefore, all existing features should have PROTECTED applied to them.
Most newly implemented features will also have PROTECTED applied because it= requires less thought and is safer.
Only considerate=C2=A0developers of features that can easily guarantee safe= ty would adopt the default.

In conclusion, this is no different from BGWORKER_INTERRUPTABLE.
Therefore, I think it's better to prioritize compatibility.

I am not sure if I understand wh= at you prefer.=C2=A0

I share your opinion that mos= t developers use options that are more safe and require less thinking (and = if this option will not be default, most developers maybe don't use=C2= =A0it in the first cycle).

At the end most bgworke= rs will be not be marked as interruptible (isn't important if we use fl= ag INTERRUPTIBLE or PROTECTED). Then proposed flag without FORCE clause wil= l be mostly inefficient - and then there is strong question if proposed fea= ture has some real benefit. I don't think so this feature should be imp= lemented and committed once, but we should to find a consensus on implement= ed behaviour in all possible cases, and all possible question.
1. When bgworker is marked as INTERRUPTIBLE, then can be cance= lled immediately - there is full agreement - I don't see any problem - = just probably almost all=C2=A0bgworkers will be not be marked as INTERRUPTI= BLE=C2=A0

2.=C2=A0 When bgworker is not marked as = INTERRUPTIBLE, then can it be cancelled? How dangerous is this? If it canno= t be cancelled, then ALTER should wait on lock forever, or there should be = some special timeout - like CREATE, DROP DATABASE and waiting on template d= atabases.

3. If the user needs to execute ALTER, t= hen probably he manually terminates the worker any time. Are currently used= workers safe against terminating? We know so mostly workers will be restar= ted after timeout - and then it is "safe".=C2=A0 It is really saf= e? Can we expect it? If it is safe, then we can implement FORCE clause. Pro= bably any worker can be restarted - and without safety it is hard to imagin= e using in the production.=C2=A0

I think there is = a fundamental question that should be solved before - what is a risk of can= celing bgworker? The possible reply is so there is not any risk for correct= ly implemented bgworkers. And then there is a question if we still need the= flag INTERRUPTIBLE? My opinion for this case is probably yes, because canc= elling can introduce some bigger latency.

Regards<= /div>

Pavel



=





=


=C2=A0

Best Regards
Ryo Matsumura
--000000000000ba34df0646d8de96--