Re: Predefined role pg_maintenance for VACUUM, ANALYZE, CHECKPOINT. - Mailing list pgsql-hackers

From Bharath Rupireddy
Subject Re: Predefined role pg_maintenance for VACUUM, ANALYZE, CHECKPOINT.
Date
Msg-id CALj2ACUJAYD1GDiRvbH-+gY2pyOFdQU7CSGc9oij1r-rK16u1w@mail.gmail.com
Whole thread Raw
In response to Re: Predefined role pg_maintenance for VACUUM, ANALYZE, CHECKPOINT.  ("Bossart, Nathan" <bossartn@amazon.com>)
Responses Re: Predefined role pg_maintenance for VACUUM, ANALYZE, CHECKPOINT.  (Jeff Davis <pgsql@j-davis.com>)
List pgsql-hackers
On Wed, Oct 27, 2021 at 3:18 AM Bossart, Nathan <bossartn@amazon.com> wrote:
>
> On 10/26/21, 2:04 PM, "Jeff Davis" <pgsql@j-davis.com> wrote:
> > Should we just add a builtin function pg_checkpoint(), and deprecate
> > the syntax?
>
> That seems reasonable to me.

IMHO, moving away from SQL command "CHECKPOINT" to function
"pg_checkpoint()" isn't nice as the SQL command has been there for a
long time and all the applications or services that were/are being
built around the postgres ecosystem would have to adapt someday to the
new function (if at all we deprecate the command and onboard the
function). This isn't good at all given the CHECKPOINT is one of the
mostly used commands in the apps or services layer. Moreover, if we go
with the function pg_checkpoint(), we might see patches coming in for
pg_vacuum(), pg_reindex(), pg_cluster() and so on.

I suggest having a predefined role (pg_maintenance or
pg_checkpoint(although I'm not sure convinced to have a separate role
just for checkpoint) or some other) and let superuser and the users
with this new predefined role do checkpoint.

Regards,
Bharath Rupireddy.



pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: Schema variables - new implementation for Postgres 15
Next
From: Michael Paquier
Date:
Subject: Opclass parameters of indexes lost after REINDEX CONCURRENTLY