Re: Predefined role pg_maintenance for VACUUM, ANALYZE, CHECKPOINT.

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: "Bossart, Nathan" <bossartn(at)amazon(dot)com>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Predefined role pg_maintenance for VACUUM, ANALYZE, CHECKPOINT.
Date: 2021-10-25 17:54:43
Message-ID: 20211025175443.GJ20998@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Greetings,

* Jeff Davis (pgsql(at)j-davis(dot)com) wrote:
> On Sun, 2021-10-24 at 21:32 +0000, Bossart, Nathan wrote:
> > My initial reaction was that members of pg_maintenance should be able
> > to do all of these things (VACUUM, ANALYZE, CLUSTER, REINDEX, and
> > CHECKPOINT).
>
> What about REFRESH MATERIALIZED VIEW? That seems more specific to a
> workload, but it's hard to draw a clear line between that and CLUSTER.

Let's not forget that there are already existing non-superusers who can
run things like REFRESH MATERIALIZED VIEW- the owner.

> > Maybe one
> > option is to have two separate roles, one for commands that require
> > lower lock levels (i.e., ANALYZE and VACUUM without TRUNCATE and
> > FULL), and another for all of the maintenance commands.
>
> My main motivation is CHECKPOINT and database-wide VACUUM and ANALYZE.
> I'm fine extending it if others think it would be worthwhile, but it
> goes beyond my use case.

I've been wondering what the actual use-case here is. DB-wide VACUUM
and ANALYZE are already able to be run by the database owner, but
probably more relevant is that DB-wide VACUUMs and ANALYZEs shouldn't
really be necessary given autovacuum, so why are we adding predefined
roles which will encourage users to do that?

I was also contemplating a different angle on this- allowing users to
request autovacuum to run vacuum/analyze on a particular table. This
would have the advantage that you get the vacuum/analyze behavior that
autovacuum has (giving up an attempted truncate lock if another process
wants a lock on the table, going at a slower pace rather than going all
out and sucking up lots of I/O, etc).

I'm not completely against this approach but just would like a bit
better understanding of why it makes sense and what things we'll be able
to say about what this role can/cannot do.

Lastly though- I dislike the name, it seems far too general. I get that
naming things is hard but maybe we could find something better than
'pg_maintenance' for this.

Thanks,

Stephen

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2021-10-25 17:58:06 Re: Experimenting with hash tables inside pg_dump
Previous Message Tom Lane 2021-10-25 17:51:56 Re: Predefined role pg_maintenance for VACUUM, ANALYZE, CHECKPOINT.