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 ...
Advertising
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 ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
