Hi! 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. On Thu, Jan 19, 2023 at 10:37 AM Alexander Pyhalov <a.pyha...@postgrespro.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/
