Horton

Re: Allow non-superuser to cancel superuser tasks.

Michael Paquier <michael@paquier.xyz>

View thread View on postgr.es
From: Michael Paquier <michael@paquier.xyz>
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: Kirill Reshke <reshkekirill@gmail.com>, "Leung, Anthony" <antholeu@amazon.com>, "Andrey M. Borodin" <x4mmm@yandex-team.ru>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2024-04-10T22:21:36Z
Lists: pgsql-hackers 
On Wed, Apr 10, 2024 at 10:00:34AM -0500, Nathan Bossart wrote:
> Isn't it relatively easy to discover this same information today via
> pg_stat_progress_vacuum?  That has the following code:
> 
> 		/* Value available to all callers */
> 		values[0] = Int32GetDatum(beentry->st_procpid);
> 		values[1] = ObjectIdGetDatum(beentry->st_databaseid);
> 
> I guess I'm not quite following why we are worried about leaking whether a
> backend is an autovacuum worker.

Good point.  I've missed that we make no effort currently to hide any
PID information from the progress tables.  And we can guess more
context data because of the per-table split of the progress tables.

This choice comes down to b6fb6471f6af that has introduced the
progress report facility, so this ship has long sailed it seems.  And
it makes my argument kind of moot.
--
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.