From: | Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp> |
---|---|
To: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
Cc: | Corey Huinker <corey(dot)huinker(at)gmail(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: vacuumdb --missing-stats-only and permission issue |
Date: | 2025-08-25 15:24:27 |
Message-ID: | 20250826002427.7cff7e20374539d58b0f0a72@sraoss.co.jp |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, 25 Aug 2025 09:29:15 -0500
Nathan Bossart <nathandbossart(at)gmail(dot)com> wrote:
> On Mon, Aug 25, 2025 at 10:30:32AM +0900, Yugo Nagata wrote:
> > The documentation fix looks good to me. However, it’s not very user-friendly that,
> > when the user lacks the required privileges, an error from the internal query is
> > raised. Instead, how about checking whether the user has the necessary privileges
> > and printing an appropriate message if any privilege is missing?
>
> Thanks for taking a look. I appreciate your suggestion, but I'm finding
> myself leaning -1 for a couple of reasons:
>
> * There's no precedent for this in vacuumdb. In fact, if the user
> specifies a nonexistent table, we return the error from the internal
> query, and if the user lacks privileges to VACUUM or ANALYZE a table, we
> let the command emit a WARNING and skip it. Intentionally or not, we
> seem to let the server do most of the work when it comes to this sort of
> thing. vacuumdb is just responsible for building and sending the
> commands.
>
> * I'm a little worried that warning about SELECT privileges on these
> catalogs will encourage people to grant privileges on them, which we
> probably don't want them to do. My proposed documentation note already
> carries some risk of this, but it at least specifically calls out that
> superusers should have the necessary privileges.
>
> * While probably rare, checking the privileges beforehand introduces race
> conditions that would cause the internal query error, anyway. I think
> there are already a few such race conditions already (e.g., if the table
> is dropped between the catalog query and the VACUUM or ANALYZE command),
> which AFAICT we just live with, but I'm wary of pressing our luck too
> much in this area.
Thank you for the clarification. I understand your points now,
so I'll withdraw my proposal.
Regards,
Yugo Nagata
--
Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp>
From | Date | Subject | |
---|---|---|---|
Next Message | Jacob Champion | 2025-08-25 15:27:53 | Re: Changing gssencmode default in Psycopg |
Previous Message | Fabrízio de Royes Mello | 2025-08-25 15:13:27 | Re: use PqMsg macros in fe-protocol3.c |