Re: vacuumdb --missing-stats-only and permission issue

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>

In response to

Responses

Browse pgsql-hackers by date

  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