Tom Lane wrote:
> In fact, maybe we should just force an autovac cycle for any DB that
> appears to be approaching wraparound, rather than waiting for the
> shutdown-before-wraparound code to kick in. Getting into that state
> amounts to whacking DBAs upside the head for being stupid, which
> doesn't really win us any friends ...
Sounds fine. How far back should we allow databases to go? If we wait
too long, pg_clog won't be truncated regularly, so I think we should do
it rather early than wait until it's close to wraparound.
> Implementation-wise, I'd propose that we add another PostmasterSignal
> event type whereby a backend could request the postmaster to launch
> an autovac process even if autovac is off. The end-of-VACUUM code that
> scans pg_database.datminxid would issue the signal if it finds anything
> seriously old.
I think we could give autovac a "reason for being started", which would
normally be the periodic stuff, but if the postmaster got the signal
from a backend, pass that info to autovac and it could use a different
database selection algorithm -- say, just select the oldest database,
even if it's not in danger of Xid wraparound. So this would allow early
database-wide vacuums for non-connectable databases (template0), and
normal per-table vacuuming for database that are in actual use.
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support