directories. This will <emphasis>not</> work because the

information contained in these files is not usable without

the commit log files,

<filename>pg_clog/*</filename>, which contain the commit status of

<filename>pg_xact/*</filename>, which contain the commit status of

all transactions. A table file is only usable with this

information. Of course it is also impossible to restore only a

table and the associated <filename>pg_clog</filename> data

table and the associated <filename>pg_xact</filename> data

because that would render all other tables in the database

cluster useless. So file system backups only work for complete

backup and restoration of an entire database cluster.

All transaction IDs before this one have been replaced with a permanent

(<quote>frozen</>) transaction ID in this table. This is used to track

whether the table needs to be vacuumed in order to prevent transaction

ID wraparound or to allow <literal>pg_clog</> to be shrunk. Zero

ID wraparound or to allow <literal>pg_xact</> to be shrunk. Zero

(<symbol>InvalidTransactionId</symbol>) if the relation is not a table.

</entry>

</row>

All transaction IDs before this one have been replaced with a permanent

(<quote>frozen</>) transaction ID in this database. This is used to

track whether the database needs to be vacuumed in order to prevent

transaction ID wraparound or to allow <literal>pg_clog</> to be shrunk.

transaction ID wraparound or to allow <literal>pg_xact</> to be shrunk.

It is the minimum of the per-table

<structname>pg_class</>.<structfield>relfrozenxid</> values.

</entry>

<para>

Vacuum also allows removal of old files from the

<filename>pg_clog</> subdirectory, which is why the default

<filename>pg_xact</> subdirectory, which is why the default

is a relatively low 200 million transactions.

This parameter can only be set at server start, but the setting

can be reduced for individual tables by

postmaster.pid | 9

pg_ident.conf | 10

global | 11

pg_clog | 12

pg_xact | 12

pg_snapshots | 13

pg_multixact | 14

PG_VERSION | 15

<para>

The sole disadvantage of increasing <varname>autovacuum_freeze_max_age</>

(and <varname>vacuum_freeze_table_age</> along with it)

is that the <filename>pg_clog</> subdirectory of the database cluster

is that the <filename>pg_xact</> subdirectory of the database cluster

will take more space, because it must store the commit status of all

transactions back to the <varname>autovacuum_freeze_max_age</> horizon.

The commit status uses two bits per transaction, so if

<varname>autovacuum_freeze_max_age</> is set to its maximum allowed

value of two billion, <filename>pg_clog</> can be expected to

value of two billion, <filename>pg_xact</> can be expected to

grow to about half a gigabyte. If this is trivial compared to your

total database size, setting <varname>autovacuum_freeze_max_age</> to

its maximum allowed value is recommended. Otherwise, set it depending

on what you are willing to allow for <filename>pg_clog</> storage.

on what you are willing to allow for <filename>pg_xact</> storage.

(The default, 200 million transactions, translates to about 50MB of

<filename>pg_clog</> storage.)

<filename>pg_xact</> storage.)

</para>

<para>

<para>

A safe value can be determined by looking for the numerically largest

file name in the directory <filename>pg_clog</> under the data directory,

file name in the directory <filename>pg_xact</> under the data directory,

adding one,

and then multiplying by 1048576 (0x100000). Note that the file names are in

hexadecimal. It is usually easiest to specify the option value in

hexadecimal too. For example, if <filename>0011</> is the largest entry

in <filename>pg_clog</>, <literal>-x 0x1200000</> will work (five

in <filename>pg_xact</>, <literal>-x 0x1200000</> will work (five

trailing zeroes provide the proper multiplier).

</para>

</listitem>

</step>

<step>

<para>

Copy all other files such as <filename>pg_clog</filename> and

Copy all other files such as <filename>pg_xact</filename> and

configuration files from the source cluster to the target cluster

(everything except the relation files).

</para>

<entry>Subdirectory containing transaction commit timestamp data</entry>

</row>

<row>

<entry><filename>pg_clog</></entry>

<entry>Subdirectory containing transaction commit status data</entry>

</row>

<row>

<entry><filename>pg_dynshmem</></entry>

<entry>Subdirectory containing files used by the dynamic shared memory

<entry>Subdirectory containing WAL (Write Ahead Log) files</entry>

</row>

<row>

<entry><filename>pg_xact</></entry>

<entry>Subdirectory containing transaction commit status data</entry>

</row>

<row>

<entry><filename>postgresql.auto.conf</></entry>

<entry>A file used for storing configuration parameters that are set by

</listitem>

<listitem>

<para>

Internal data structures such as <filename>pg_clog</filename>, <filename>pg_subtrans</filename>, <filename>pg_multixact</filename>,

Internal data structures such as <filename>pg_xact</filename>, <filename>pg_subtrans</filename>, <filename>pg_multixact</filename>,

<filename>pg_serial</filename>, <filename>pg_notify</filename>, <filename>pg_stat</filename>, <filename>pg_snapshots</filename> are not directly

checksummed, nor are pages protected by full page writes. However, where

such data structures are persistent, WAL records are written that allow