Re: allow granting CLUSTER, REFRESH MATERIALIZED VIEW, and REINDEX - Mailing list pgsql-hackers

From Nathan Bossart
Subject Re: allow granting CLUSTER, REFRESH MATERIALIZED VIEW, and REINDEX
Date
Msg-id 20221216051354.GB804311@nathanxps13
Whole thread Raw
In response to Re: allow granting CLUSTER, REFRESH MATERIALIZED VIEW, and REINDEX  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: allow granting CLUSTER, REFRESH MATERIALIZED VIEW, and REINDEX
List pgsql-hackers
On Thu, Dec 15, 2022 at 08:35:53PM -0800, Jeff Davis wrote:
> But why make CLUSTER more like VACUUM? Shouldn't we make
> VACUUM/CLUSTER/ANALYZE more like INSERT/SELECT/REINDEX?

Hm.  Since VACUUM may happen across multiple transactions, it is careful to
re-check the privileges for each relation.  For example, vacuum_rel()
contains this comment:

    /*
     * Check if relation needs to be skipped based on privileges.  This check
     * happens also when building the relation list to vacuum for a manual
     * operation, and needs to be done additionally here as VACUUM could
     * happen across multiple transactions where privileges could have changed
     * in-between.  Make sure to only generate logs for VACUUM in this case.
     */

I do wonder whether this is something we really need to be concerned about.
In the worst case, you might be able to VACUUM a table with a concurrent
owner change.

The logic for gathering all relations to process (i.e.,
get_all_vacuum_rels() and get_tables_to_cluster()) would also need to be
adjusted to handle partitioned tables.  Right now, we gather all the
partitions and checks privileges on each.  I think this would be easy to
change.

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com



pgsql-hackers by date:

Previous
From: Paul Jungwirth
Date:
Subject: Re: Exclusion constraints on partitioned tables
Next
From: Nathan Bossart
Date:
Subject: Re: allow granting CLUSTER, REFRESH MATERIALIZED VIEW, and REINDEX