Horton

Re: Allow non-superuser to cancel superuser tasks.

Nathan Bossart <nathandbossart@gmail.com>

View thread View on postgr.es
From: Nathan Bossart <nathandbossart@gmail.com>
To: Andres Freund <andres@anarazel.de>
Cc: Alexander Kukushkin <cyberdemn@gmail.com>, "Andrey M. Borodin" <x4mmm@yandex-team.ru>, Michael Paquier <michael@paquier.xyz>, Kirill Reshke <reshkekirill@gmail.com>, "Leung, Anthony" <antholeu@amazon.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2024-11-23T02:44:34Z
Lists: pgsql-hackers

Attachments

On Fri, Nov 22, 2024 at 06:13:16PM -0500, Andres Freund wrote:
>> -		if (procStatus && procStatus->st_backendType == B_AUTOVAC_WORKER)
>> +		if (pgstat_get_backend_type(pid) == B_AUTOVAC_WORKER)
> 
> Because we already mapped the pid to a ProcNumber, it'd be cheaper to access
> the backend status via procnumber.

D'oh, I missed that ProcNumber could be used as an index for the
BackendStatusArray.  Is the attached more like what you are imagining?

> We don't need the pgstat_begin_read_activity() protocol when just accessing a
> single 4 byte value - we assume in lots of places that can be read in a
> non-tearable way.
> 
>> +			if (pgstat_read_activity_complete(before_changecount,
>> +											  after_changecount))
>> +				break;
>> +
>> +			CHECK_FOR_INTERRUPTS();
>> +		}
>> +
>> +		if (found)
>> +			return beentry->st_backendType;
> 
> But if we were to follow it, we'd certainly need to use it here too.

I see.

-- 
nathan

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.