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

Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> 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.

I don't think it's worth the trouble to provide such a signaling
mechanism (it'd be a bit of a PITA to make it work in both fork and
EXEC_BACKEND cases). ISTM it's sufficient for autovac to look at the
GUC state and notice whether it's nominally enabled or not. If not,
it should only consider anti-wraparound vacuum operations.

If the signal is given just when VACUUM sees a datvacuumxid value that's
old enough to cause autovac to decide it had better go prevent
wraparound, then this will work without any additional data transfer.
We could negotiate exactly how old DBs need to be to cause this; if you
want to make it less than a billion xacts so that we can keep pg_clog
cut down to size, that's fine with me.

regards, tom lane