Thanks for taking a look. On Wed, Mar 01, 2023 at 03:31:48PM +0900, Michael Paquier wrote: > PROCESS_TOAST has that: > /* sanity check for PROCESS_TOAST */ > if ((params->options & VACOPT_FULL) != 0 && > (params->options & VACOPT_PROCESS_TOAST) == 0) > ereport(ERROR, > (errcode(ERRCODE_FEATURE_NOT_SUPPORTED), > errmsg("PROCESS_TOAST required with VACUUM FULL"))); > [...] > - if (params->options & VACOPT_FULL) > + if (params->options & VACOPT_FULL && > + params->options & VACOPT_PROCESS_MAIN) > { > > Shouldn't we apply the same rule for PROCESS_MAIN? One of the > regression tests added means that FULL takes priority over > PROCESS_MAIN=FALSE, which is a bit confusing IMO.
I don't think so. We disallow FULL without PROCESS_TOAST because there presently isn't a way to VACUUM FULL the main relation without rebuilding its TOAST table. However, FULL without PROCESS_MAIN can be used to run VACUUM FULL on only the TOAST table. > @@ -190,6 +190,7 @@ typedef struct VacAttrStats > #define VACOPT_DISABLE_PAGE_SKIPPING 0x80 /* don't skip any pages */ > #define VACOPT_SKIP_DATABASE_STATS 0x100 /* skip vac_update_datfrozenxid() > */ > #define VACOPT_ONLY_DATABASE_STATS 0x200 /* only vac_update_datfrozenxid() > */ > +#define VACOPT_PROCESS_MAIN 0x400 /* process main relation */ > > Perhaps the options had better be reorganized so as PROCESS_MAIN is > just before PROCESS_TOAST? Sure. > +-- PROCESS_MAIN option > +VACUUM (PROCESS_MAIN FALSE) vactst; > +VACUUM (PROCESS_MAIN FALSE, PROCESS_TOAST FALSE) vactst; > +VACUUM (PROCESS_MAIN FALSE, FULL) vactst; > > Thinking a bit here. This set of tests does not make sure that the > main relation and/or the toast relation have been actually processed. > pg_stat_user_tables does not track what's happening on the toast > relations. So... What about adding some tests in 100_vacuumdb.pl > that rely on vacuumdb --verbose and check the logs produced? We > should make sure that the toast or the main relation are processed, > by tracking, for example, logs like vacuuming "schema.table". When > FULL is involved, we may want to track the changes on relfilenodes > depending on what's wanted. That seems like a good idea. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com