Re: [HACKERS] Non-transactional pg_class, try 2

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