For the test Alexander described in the beginning of the discussion - the results are
postgres@postgres=# set role regress_vacuum_conflict; SET Time: 0.324 ms postgres@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@postgres=> vacuum full; WARNING: permission denied to vacuum "pg_statistic", skipping it WARNING: permission denied to vacuum "vacuum_tab", skipping it
...
postgres@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.
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