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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026