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

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: "Ryo Matsumura (Fujitsu)" <matsumura(dot)ryo(at)fujitsu(dot)com>
Cc: "Aya Iwata (Fujitsu)" <iwata(dot)aya(at)fujitsu(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Peter Smith <smithpb2250(at)gmail(dot)com>, Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PROPOSAL] Termination of Background Workers for ALTER/DROP DATABASE
Date: 2025-12-26 11:04:47
Message-ID: CAFj8pRBtApX5WGMOzz4+_xe3ZvBLc6BsrUV13KTeNpAL6ZxFzA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi

pá 26. 12. 2025 v 11:17 odesílatel Ryo Matsumura (Fujitsu) <
matsumura(dot)ryo(at)fujitsu(dot)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
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2025-12-26 11:16:42 Re: 17f446784d54da827f74c2acc0fa772a41b92354 breaks orafce build
Previous Message Nazir Bilal Yavuz 2025-12-26 10:59:24 Re: Streamify more code paths