Re: Allow non-superuser to cancel superuser tasks.

Michael Paquier <michael@paquier.xyz>

From: Michael Paquier <michael@paquier.xyz>
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: "Andrey M. Borodin" <x4mmm@yandex-team.ru>, Kirill Reshke <reshkekirill@gmail.com>, "Leung, Anthony" <antholeu@amazon.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2024-07-15T00:54:43Z
Lists: pgsql-hackers
On Fri, Jul 12, 2024 at 11:19:05AM -0500, Nathan Bossart wrote:
> I suppose it would be silly to allow even lower values for
> autovacuum_naptime (e.g., by moving it to ConfigureNamesReal and setting
> the minimum to 0.1).

I've thought about that as well, and did not mention it as this would
encourage insanely low naptime values resulting in fork() bursts.

> That's a neat trick.  I was confused why this test generates an autovacuum
> worker at all, but I now see that you are pausing it before we even gather
> the list of tables that need to be vacuumed.

Yep.  More aggressive signals aren't going to help.  One thing I also
considered here is to manipulate the db list timestamps inside a
USE_INJECTION_POINTS block in the launcher to make the spawn more
aggressive.  Anyway, with 600ms in detection where I've tested it, I
can live with the responsiveness of the patch as proposed.

> Looks reasonable to me.

Thanks.  I'll see about stressing the buildfarm tomorrow or so, after
looking at how the CI reacts.
--
Michael

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.