11<!--
2- $Header: /cvsroot/pgsql/doc/src/sgml/maintenance.sgml,v 1.1 2001/08/26 21:17:12 tgl Exp $
2+ $Header: /cvsroot/pgsql/doc/src/sgml/maintenance.sgml,v 1.2 2001/08/27 23:42:34 tgl Exp $
33-->
44
55<chapter id="maintenance">
@@ -226,7 +226,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/maintenance.sgml,v 1.1 2001/08/26 21:17:12
226226 than 4 billion transactions) will suffer <firstterm>transaction ID
227227 wraparound</>: the XID counter wraps around to zero, and all of a sudden
228228 transactions that were in the past appear to be in the future --- which
229- means their outputs become invisible. In short,catatrophic data loss.
229+ means their outputs become invisible. In short,catastrophic data loss.
230230 (Actually the data is still there, but that's cold comfort if you can't
231231 get at it.)
232232 </para>
@@ -237,9 +237,9 @@ $Header: /cvsroot/pgsql/doc/src/sgml/maintenance.sgml,v 1.1 2001/08/26 21:17:12
237237 transactions. This of course was not very satisfactory for high-traffic
238238 sites, so a better solution has been devised. The new approach allows an
239239 installation to remain up indefinitely, without initdb or any sort of
240- restart. The price is this maintenance requirement: <emphasis>every table
241- in the database must be VACUUMedmore often than once every billion
242- transactions</emphasis>.
240+ restart. The price is this maintenance requirement:
241+ <emphasis>every table in the database must be VACUUMedat least once every
242+ billion transactions</emphasis>.
243243 </para>
244244
245245 <para>
@@ -261,7 +261,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/maintenance.sgml,v 1.1 2001/08/26 21:17:12
261261 Therefore, once a tuple has been created with a particular normal XID, the
262262 tuple will appear to be <quote>in the past</> for the next two billion
263263 transactions, no matter which normal XID we are talking about. If the
264- tuple still exists after more than two billion transactions, itwould
264+ tuple still exists after more than two billion transactions, itwill
265265 suddenly appear to be in the future. To prevent data loss, old tuples
266266 must be reassigned the XID <literal>FrozenXID</> sometime before they reach
267267 the two-billion-transactions-old mark. Once they are assigned this
@@ -276,8 +276,8 @@ $Header: /cvsroot/pgsql/doc/src/sgml/maintenance.sgml,v 1.1 2001/08/26 21:17:12
276276 to any tuple with a normal XID more than one billion transactions in the
277277 past. This policy preserves the original insertion XID until it is not
278278 likely to be of interest anymore (in fact, most tuples will probably
279- live and die without ever being <quote>frozen</>).This policy means
280- that the maximum safe interval between <command>VACUUM</>s of any table
279+ live and die without ever being <quote>frozen</>).With this policy,
280+ the maximum safe interval between <command>VACUUM</>s of any table
281281 is exactly one billion transactions: if you wait longer, it's possible
282282 that a tuple that was not quite old enough to be reassigned last time
283283 is now more than two billion transactions old and has wrapped around
@@ -335,7 +335,7 @@ VACUUM
335335 to be considered good by all open transactions. In particular, if
336336 a <command>VACUUM FREEZE</> is performed in an otherwise-idle database,
337337 it is guaranteed that <emphasis>all</> tuples in that database will be
338- frozen. Hence, as long the database is not modified in any way, it
338+ frozen. Hence, as longas the database is not modified in any way, it
339339 will not need subsequent vacuuming to avoid transaction ID wraparound
340340 problems. This technique is used by <filename>initdb</> to prepare the
341341 <filename>template0</> database. It should also be used to prepare any