|From:||Michael Paquier <michael(at)paquier(dot)xyz>|
|To:||Nathan Bossart <nathandbossart(at)gmail(dot)com>|
|Cc:||Jeff Davis <pgsql(at)j-davis(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Pavel Luzanov <p(dot)luzanov(at)postgrespro(dot)ru>, pgsql-hackers(at)postgresql(dot)org|
|Subject:||Re: allow granting CLUSTER, REFRESH MATERIALIZED VIEW, and REINDEX|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On Wed, Dec 14, 2022 at 03:29:39PM -0800, Nathan Bossart wrote:
> On Wed, Dec 14, 2022 at 11:05:13AM -0800, Jeff Davis wrote:
>> On Wed, 2022-12-14 at 10:16 -0800, Nathan Bossart wrote:
>>> Okay. Should all the privileges governed by MAINTAIN apply to a
>>> TOAST table as well?
>> Yes, I agree.
> This might be tricky, because AFAICT you have to scan pg_class to find a
> TOAST table's main relation.
Ugh, yeah. Are we talking about a case where we know the toast
information but need to look back at some information of its parent to
do a decision? I don't recall a case where we do that. CLUSTER,
REINDEX and VACUUM lock first the parent when working on it, and no
AEL is taken on the parent if doing directly a VACUUM or a REINDEX on
the toast table, so that could lead to deadlock scenarios. Shouldn't
MAINTAIN be sent down to the toast table as well if that's not done
FWIW, I have briefly poked at that here:
|Next Message||Jeff Davis||2022-12-15 00:18:05||Re: allow granting CLUSTER, REFRESH MATERIALIZED VIEW, and REINDEX|
|Previous Message||Jonathan S. Katz||2022-12-15 00:00:54||Re: Raising the SCRAM iteration count|