From bc7d37a525c02f4a0e983854c4222e9d063eeae2 Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Sun, 26 Aug 2001 16:56:03 +0000 Subject: Transaction IDs wrap around, per my proposal of 13-Aug-01. More documentation to come, but the code is all here. initdb forced. --- doc/src/sgml/catalogs.sgml | 27 +++++++++++++++++-- doc/src/sgml/ref/create_database.sgml | 16 +++++++++++- doc/src/sgml/ref/vacuum.sgml | 49 ++++++++++++++++++++++++++--------- 3 files changed, 77 insertions(+), 15 deletions(-) (limited to 'doc/src') diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml index e2c3139d853..39c05e24bd8 100644 --- a/doc/src/sgml/catalogs.sgml +++ b/doc/src/sgml/catalogs.sgml @@ -1,6 +1,6 @@ @@ -840,11 +840,34 @@ oid - Last oid in existence after the database was created; useful + Last system OID in the database; useful particularly to pg_dump + + datvacuumxid + xid + + + All tuples inserted or deleted by transaction IDs before this one + have been marked as known committed or known aborted in this database. + This is used to determine when commit-log space can be recycled. + + + + + datfrozenxid + xid + + + All tuples inserted by transaction IDs before this one have been + relabeled with a permanent (frozen) transaction ID in this + database. This is useful to check whether a database must be vacuumed + soon to avoid transaction ID wraparound problems. + + + datpath text diff --git a/doc/src/sgml/ref/create_database.sgml b/doc/src/sgml/ref/create_database.sgml index e128c1891d0..20477ac191c 100644 --- a/doc/src/sgml/ref/create_database.sgml +++ b/doc/src/sgml/ref/create_database.sgml @@ -1,5 +1,5 @@ @@ -284,6 +284,20 @@ comment from Olly; response from Thomas... simply by setting the flag false). The template0 database is normally marked this way to prevent modification of it. + + + After preparing a template database, or making any changes to one, + it is a good idea to perform + VACUUM FREEZE or VACUUM FULL FREEZE in that + database. If this is done when there are no other open transactions + in the same database, then it is guaranteed that all tuples in the + database are frozen and will not be subject to transaction + ID wraparound problems. This is particularly important for a database + that will have datallowconn set to false, since it + will be impossible to do routine maintenance VACUUMs on + such a database. + See the Administrator's Guide for more information. + diff --git a/doc/src/sgml/ref/vacuum.sgml b/doc/src/sgml/ref/vacuum.sgml index e8374725b34..62e47a7086d 100644 --- a/doc/src/sgml/ref/vacuum.sgml +++ b/doc/src/sgml/ref/vacuum.sgml @@ -1,5 +1,5 @@ @@ -20,11 +20,11 @@ Postgres documentation - 2001-07-10 + 2001-08-26 -VACUUM [ FULL ] [ VERBOSE ] [ table ] -VACUUM [ FULL ] [ VERBOSE ] ANALYZE [ table [ (column [, ...] ) ] ] +VACUUM [ FULL ] [ FREEZE ] [ VERBOSE ] [ table ] +VACUUM [ FULL ] [ FREEZE ] [ VERBOSE ] ANALYZE [ table [ (column [, ...] ) ] ] @@ -46,6 +46,14 @@ VACUUM [ FULL ] [ VERBOSE ] ANALYZE [ table + + FREEZE + + + Selects aggressive freezing of tuples. + + + VERBOSE @@ -169,21 +177,38 @@ NOTICE: Index index: Pages 28; - Plain VACUUM simply reclaims space and makes it + VACUUM ANALYZE performs a VACUUM + and then an ANALYZE for each selected table. This + is a handy combination form for routine maintenance scripts. See + + for more details about its processing. + + + + Plain VACUUM (without FULL) simply reclaims + space and makes it available for re-use. This form of the command can operate in parallel with normal reading and writing of the table. VACUUM FULL does more extensive processing, including moving of tuples across blocks to try to compact the table to the minimum number of disk - blocks. This is much slower and requires an exclusive lock on each table - while it is being processed. + blocks. This form is much slower and requires an exclusive lock on each + table while it is being processed. - VACUUM ANALYZE performs a VACUUM - and then an ANALYZE for each selected table. This - is a handy combination form for routine maintenance scripts. See - - for more details about its processing. + FREEZE is a special-purpose option that + causes tuples to be marked frozen as soon as possible, + rather than waiting until they are quite old. If this is done when there + are no other open transactions in the same database, then it is guaranteed + that all tuples in the database are frozen and will not be + subject to transaction ID wraparound problems, no matter how long the + database is left un-vacuumed. + FREEZE is not recommended for routine use. Its only + intended usage is in connection with preparation of user-defined template + databases, or other databases that are completely read-only and will not + receive routine maintenance VACUUM operations. + See + for details. -- cgit v1.2.3