Re: Inconsistency in vacuum behavior

Hi!

For the test Alexander described in the beginning of the discussion - the
results are
postgres(at)postgres=# set role regress_vacuum_conflict;
SET
Time: 0.324 ms
postgres(at)postgres=> vacuum vacuum_tab;
WARNING: permission denied to vacuum "vacuum_tab", skipping it
WARNING: permission denied to vacuum "vacuum_tab_1", skipping it
WARNING: permission denied to vacuum "vacuum_tab_2", skipping it
VACUUM
Time: 1.782 ms
postgres(at)postgres=> vacuum full;
WARNING: permission denied to vacuum "pg_statistic", skipping it
WARNING: permission denied to vacuum "vacuum_tab", skipping it
...
postgres(at)postgres=> cluster vacuum_tab;
ERROR: must be owner of table vacuum_tab
Time: 0.384 ms

For the standard role "Postgres" the behavior is the same as before patch.

On Thu, Jan 19, 2023 at 10:37 AM Alexander Pyhalov <a(dot)pyhalov(at)postgrespro(dot)ru>
wrote:

> Justin Pryzby писал 2023-01-19 04:49:
> > On Mon, Jan 16, 2023 at 08:12:18PM +0300, Nikita Malakhov wrote:
> >> Hi,
> >>
> >> Currently there is no error in this case, so additional thrown error
> >> would
> >> require a new test.
> >> Besides, throwing an error here does not make sense - it is just a
> >> check
> >> for a vacuum
> >> permission, I think the right way is to just skip a relation that is
> >> not
> >> suitable for vacuum.
> >> Any thoughts or objections?
> >
> > Could you check if this is consistent between the behavior of VACUUM
> > FULL and CLUSTER ? See also Nathan's patches.
>
> Hi.
>
> Cluster behaves in a different way - it errors out immediately if
> relation is not owned by user. For partitioned rel it would anyway raise
> error later.
> VACUUM and VACUUM FULL behave consistently after applying Nikita's patch
> (for partitioned and regular tables) - issue warning "skipping
> TABLE_NAME --- only table or database owner can vacuum it" and return
> success status.
>
> --
> Best regards,
> Alexander Pyhalov,
> Postgres Professional
>

--
Regards,
Nikita Malakhov
Postgres Professional
https://postgrespro.ru/