Re: Surviving transaction-ID wraparound, take 2

> 3. VACUUM will have the responsibility of replacing old normal XIDs with
> FrozenXID.  It will do this whenever a committed-good tuple has xmin less
> than a cutoff XID.  (There is no need to replace xmax, since if xmax is
> committed good then the tuple itself will be removed.)  The cutoff XID
> could be anything less than XmaxRecent (the oldest XID that might be
> considered still running by any current transaction).  I believe that by
> default it ought to be pretty old, say 1 billion transactions in the past.
> This avoids expending I/O to update tuples that are unlikely to live long;
> furthermore, keeping real XIDs around for some period of time is useful
> for debugging.
> 
> 4. To make this work, VACUUM must be run on every table at least once
> every billion transactions.  To help keep track of this maintenance
> requirement, we'll add two columns to pg_database.  Upon successful
> completion of a database-wide (all tables) VACUUM, VACUUM will update the
> current database's row in pg_database with the cutoff XID and XmaxRecent
> XID that it used.  Inspection of pg_database will then show which
> databases are in need of re-vacuuming.  The use of the XmaxRecent entry
> will be explained below.

I like the 1 billion in the past idea, and recording it in pg_database
so we can quickly know how far back we can go to recycle xids.  Nice.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026