Re: Allow non-superuser to cancel superuser tasks.

On Tue, 27 Feb 2024 at 01:22, Kirill Reshke <reshkekirill(at)gmail(dot)com> wrote:

>
>
> On Mon, 26 Feb 2024 at 20:10, Nathan Bossart <nathandbossart(at)gmail(dot)com>
> wrote:
>
>> On Mon, Feb 26, 2024 at 12:38:40PM +0500, Kirill Reshke wrote:
>> > I see 2 possible ways to implement this. The first one is to have hool
>> in
>> > pg_signal_backend, and define a hook in extension which can do the
>> thing.
>> > The second one is to have a predefined role. Something like a
>> > `pg_signal_autovacuum` role which can signal running autovac to cancel.
>> But
>> > I don't see how we can handle specific `application_name` with this
>> > solution.
>>
>> pg_signal_autovacuum seems useful given commit 3a9b18b.
>>
>> --
>> Nathan Bossart
>> Amazon Web Services: https://aws.amazon.com
>
>
> Thank you for your response.
> Please find a patch attached.
>
> In patch, pg_signal_autovacuum role with oid 6312 added. I grabbed oid
> from unused_oids script output.
> Also, tap tests for functionality added. I'm not sure where to place them,
> so I placed them in a separate directory in `src/test/`
> Seems that regression tests for this feature are not possible, am i right?
> Also, I was thinking of pg_signal_autovacuum vs pg_signal_backend.
> Should pg_signal_autovacuum have power of pg_signal_backend (implicity)?
> Or should this role have such little scope...
>
> Have a little thought on this, will share.
Do we need to test the pg_cancel_backend vs autovacuum case at all?
I think we do. Would it be better to split work into 2 patches: first one
with tests against current logic, and second
one with some changes/enhancements which allows to cancel running autovac
to non-superuser (via `pg_signal_autovacuum` role or some other mechanism)?