On Wed, Dec 19, 2018 at 08:50:10PM +0000, Bossart, Nathan wrote: > If an option is specified for a server version that is not supported, > the option is silently ignored. For example, SKIP_LOCKED was only > added to VACUUM and ANALYZE for v12. Alternatively, I think we could > fail in vacuum_one_database() if an unsupported option is specified. > Some of these options will work on all currently supported versions, > so I am curious what others think about skipping some of these version > checks altogether.
prepare_vacuum_command() already handles that by ignoring silently unsupported options (see the case of SKIP_LOCKED). So why not doing the same? > It does not seem clear whether the user wants us to process mytable > only if it is at least 1 GB, or if we should process mytable in > addition to any other relations over 1 GB. Either way, I think trying > to support these combinations of options adds more complexity than it > is worth. It seems to me that a combination of both options means that the listed table should be processed only if its minimum size is 1GB. If multiple tables are specified with --table, then only those reaching 1GB would be processed. So this restriction can go away. The same applies for the proposed --min-xid-age and --min-mxid-age. + <para> + Only execute the vacuum or analyze commands on tables with a multixact + ID age of at least <replaceable class="parameter">mxid_age</replaceable>. + </para> Adding a link to explain the multixact business may be helpful, say vacuum-for-multixact-wraparound. Same comment for XID. > 0001 is a minor fix that is somewhat separate from these new options, > although the new options will make the edge case it aims to fix much > easier to reach. When the catalogs are queried in parallel mode to > get the list of tables to process, we currently assume that at least > one table will be returned. If no tables are found, the tables > variable will stay as NULL, which leads to database-wide VACUUM or > ANALYZE commands. Since there are currently no user-configurable > options available for this catalog query, this case is likely > exceptionally rare. However, with the new options, it is much easier > to inadvertently filter out all relations. Agreed. No need to visibly bother about that in back-branches. There is an argument about also adding DISABLE_PAGE_SKIPPING. -- Michael
signature.asc
Description: PGP signature
