Re: Allow non-superuser to cancel superuser tasks.

Kirill Reshke <reshkekirill@gmail.com>

From: Kirill Reshke <reshkekirill@gmail.com>
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: pgsql-hackers@postgresql.org
Date: 2024-02-26T20:22:31Z
Lists: pgsql-hackers

Attachments

On Mon, 26 Feb 2024 at 20:10, Nathan Bossart <nathandbossart@gmail.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...

Commits

  1. Look up backend type in pg_signal_backend() more cheaply.

  2. Add tap test for pg_signal_autovacuum role

  3. Introduce pg_signal_autovacuum_worker.

  4. Add a slot synchronization function.

  5. Ban role pg_signal_backend from more superuser backend types.