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 |
Date: | 2022-12-15 00:12:26 |
Message-ID: | Y5pmaksAYyJbSU77@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
>>> relation's
>>> 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
this way?
FWIW, I have briefly poked at that here:
https://www.postgresql.org/message-id/YZI+aNEnnpBASxNU@paquier.xyz
--
Michael
From | Date | Subject | |
---|---|---|---|
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 |