Greetings, * Andres Freund (and...@anarazel.de) wrote: > On 2021-11-05 08:42:58 -0400, Robert Haas wrote: > > On Thu, Nov 4, 2021 at 7:38 PM Jeff Davis <pg...@j-davis.com> wrote: > > > It seems like this specific approach has been mostly shot down already. > > > But out of curiosity, are you intending to run CHECKPOINT during > > > bootstrap or something? > > > > Imagine a system with corruption in pg_proc. Right now, that won't > > prevent you from successfully executing a checkpoint. With this > > approach, it might. > > Exactly. It wouldn't matter if checkpoints weren't something needed to > potentially bring the system back into a sane state, but ...
This really isn't that hard to address- do a superuser check, if it passes then just call the checkpoint function like CHECKPOINT; does today. Otherwise, check the perms on the function or just call the function in a manner which would check privileges, or maybe have another predefined role, though I continue to feel like the function based approach is better. If we're actually worried about catalog corruption (and, frankly, I've got some serious doubts that jumping in and running CHECKPOINT; by hand is a great idea if there's such active corruption) then we must use such an approach no matter how we allow non-superusers to run the command because any approach to that necessarily involves some amount of catalog access. Any concern leveraged against pg_proc applies equally to pg_auth_members after all, so having it be something role-based vs. function privilege is really just moving deck chairs around on the titanic at that point. Thanks, Stephen
signature.asc
Description: PGP signature
