> 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 [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
