From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
---|---|
To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
Cc: | Ted Yu <yuzhihong(at)gmail(dot)com>, Pavel Luzanov <p(dot)luzanov(at)postgrespro(dot)ru>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: allow granting CLUSTER, REFRESH MATERIALIZED VIEW, and REINDEX |
Date: | 2023-01-13 20:33:34 |
Message-ID: | 20230113203334.GA2206335@nathanxps13 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jan 13, 2023 at 11:56:03AM -0800, Jeff Davis wrote:
> I'm hesitant to add an index to pg_class just for the privilege checks
> on toast tables, and I don't think we need to.
I bet this index will be useful for more than just these privilege checks
(e.g., autovacuum currently creates a hash table for the
toast-to-main-relation mapping), but I do understand the hesitation.
> Instead, we can just
> skip the privilege check on a toast table if it's not referenced
> directly, because we already checked the privileges on the parent, and
> we still hold the session lock so nothing strange should have happened.
That would fix the problem in the original complaint, but it wouldn't allow
for vacuuming toast tables directly if you only have MAINTAIN privileges on
the main relation. If you can vacuum the toast table indirectly via the
main relation, shouldn't it be possible to vacuum it directly?
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Wong | 2023-01-13 20:45:36 | Re: real/float example for testlibpq3 |
Previous Message | Tom Lane | 2023-01-13 20:25:16 | Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc? |