| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
| Cc: | Kirill Reshke <reshkekirill(at)gmail(dot)com>, "Leung, Anthony" <antholeu(at)amazon(dot)com>, "Andrey M(dot) Borodin" <x4mmm(at)yandex-team(dot)ru>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Allow non-superuser to cancel superuser tasks. |
| Date: | 2024-04-10 22:21:36 |
| Message-ID: | ZhcQ8Ki3Ck6VlYqu@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2024-04-10 22:37:00 | Re: Improve eviction algorithm in ReorderBuffer |
| Previous Message | Nathan Bossart | 2024-04-10 21:51:49 | Re: recovery modules |