Re: [HACKERS] Non-transactional pg_class, try 2 - Mailing list pgsql-patches

Tom Lane wrote:
> Alvaro Herrera <alvherre@commandprompt.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.

Committed.  I didn't do anything but the simplest stuff; autovacuum
checks whether it's enabled in GUC, and if it doesn't then it just picks
the oldest database and issues a database-wide vacuum.  The
vac_truncate_clog routine will send a signal at the same time as the
WARNING about nearing Xid wraparound would be emitted.

One funny thing I noticed is that if there is more than one database
needing db-wide vacuum, vacuum will send a signal; autovacuum will
process one database; and autovacuum will send a signal as well when
it's done because of the other databases.  But autovacuum will get the
second signal and do nothing, because of the code to check for frequent
autovacuum starts.  This kind of suprised me at first but it's really to
be expected.  I considered disabling that timing code in the case of
getting the signal, but I don't think it's worth it.

One important improvement we'd may want to do is changing vacuum so that
it only calls vac_truncate_clog once if invoked by autovacuum (currently
it'll be called every time a table is vacuumed).  Also I think we could
change the OldestXmin stuff so that it only takes database-local
transactions into account for non-shared tables.

But in the spirit of incremental improvement I think we're much better
now.

Happy sprinting to everyone,

--
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.