On Tue, Dec 21, 2021 at 10:39 PM Masahiko Sawada <sawada.m...@gmail.com> wrote: > > On Wed, Dec 22, 2021 at 6:56 AM Peter Geoghegan <p...@bowt.ie> wrote: > > > > This new command/facility should probably not be a new flag to the > > VACUUM command, as such. Rather, I think that it should either be an > > SQL-callable function, or a dedicated top-level command (that doesn't > > accept any tables). The only reason to have this is for scenarios > > where the user is already in a tough spot with wraparound failure, > > like that client of yours. Nobody wants to force the failsafe for one > > specific table. It's not general purpose, at all, and shouldn't claim > > to be. > > Even not in the situation where the database has to run as the > single-user mode to freeze tuples, I think there would be some use > cases where users want to run vacuum (in failsafe mode) on tables with > relfrozenxid/relminmxid greater than their failsafe thresholds before > falling into that situation. I think it’s common that users are > somehow monitoring relfrozenxid/relminmxid and want to manually run > vacuum on them rather than relying on autovacuums. --min-xid-age > option and --min-mxid-age option of vacuumdb command would be good > examples. So I think this new command/facility might not necessarily > need to be specific to single-user mode.
If we want to leave open the possibility to specify these parameters, a SQL-callable function seems like the way to go. And even if we don't, a function is fine. -- John Naylor EDB: http://www.enterprisedb.com
