At Tue, 24 Jul 2018 14:23:02 +0900, Michael Paquier <mich...@paquier.xyz> wrote in <20180724052302.gb4...@paquier.xyz> > On Mon, Jul 23, 2018 at 09:51:54PM -0700, Andres Freund wrote: > > On July 23, 2018 9:50:10 PM PDT, Michael Paquier <mich...@paquier.xyz> > > wrote: > >> Oh, yes, that would be bad. My mind has slipped here. I have seen > >> manual VACUUMs on system catalogs for applications using many temp > >> tables... So we would want to have only VACUUM FULL being > >> conditionally > >> happening? The question comes then about what to do when a VACUUM FULL > >> is run without a list of relations because expand_vacuum_rel() is not > >> actually the only problem. Would we want to ignore system tables as > >> well except if allow_system_table_mods is on? When no relation list is > >> specified, get_all_vacuum_rels() builds the list of relations which > >> causes vacuum_rel() to complain on try_relation_open(), so patching > >> just expand_vacuum_rel() solves only half of the problem for manual > >> VACUUMs. > > > > I think any such restriction is entirely unacceptable. FULL or not. > > Well, letting any users attempt to take an exclusive lock which > makes others to be stuck as well is not acceptable either, so > two possible answers would be to fail > or skip such relations. The first concept applies if a relation list is > given by the user, and the second if no list is given. > > Do you have any thoughts on the matter?
I'm not sure what is the exact problem here. If it is that a non-privilege user can stuck on VACUUM FULL on the scenario, we should just give up VACUUM_FULLing on unprivileged relations *before* trying to take a lock on it. There's no reason for allowing VACUUM FULL on a relation on that the same user is not allowed to run VACUUM. I don't think it's a prbolem that superuser can be involed in the blocking scenario running VACUUM FULL. I may be misunderstanding something because (really ?) it's still extremely hot in Japan, today. regards. -- Kyotaro Horiguchi NTT Open Source Software Center