PG_RESETXLOG(1) PostgreSQL Server Applications PG_RESETXLOG(1)NAMEpg_resetxlog - reset write-ahead log and pg_control con-
tents
SYNOPSISpg_resetxlog [ -f ] [ -n ] [ -o oid ] [ -x xid ] [
-l fileid,seg ] datadir
DESCRIPTIONpg_resetxlog clears the write-ahead log and optionally
resets some fields in the pg_control file. This function
is sometimes needed if these files have become corrupted.
It should be used only as a last resort, when the server
will not start due to such corruption.
After running this command, it should be possible to start
the server, but bear in mind that the database may contain
inconsistent data due to partially-committed transactions.
You should immediately dump your data, run initdb, and
reload. After reload, check for inconsistencies and repair
as needed.
This utility can only be run by the user who installed the
server, because it requires read/write access to the
datadir. For safety reasons, you must specify the data
directory on the command line. pg_resetxlog does not use
the environment variable PGDATA.
If pg_resetxlog complains that it cannot determine valid
data for pg_control, you can force it to proceed anyway by
specifying the -f (force) switch. In this case plausible
values will be substituted for the missing data. Most of
the fields can be expected to match, but manual assistance
may be needed for the next OID, next transaction ID, WAL
starting address, and database locale fields. The first
three of these can be set using the switches discussed
below. pg_resetxlog's own environment is the source for
its guess at the locale fields; take care that LANG and so
forth match the environment that initdb was run in. If
you are not able to determine correct values for all these
fields, -f can still be used, but the recovered database
must be treated with even more suspicion than usual --- an
immediate dump and reload is imperative. Do not execute
any data-modifying operations in the database before you
dump, as any such action is likely to make the corruption
worse.
The -o, -x, and -l switches allow the next OID, next
transaction ID, and WAL starting address values to be set
manually. These are only needed when pg_resetxlog is
unable to determine appropriate values by reading pg_con-
trol. A safe value for the next transaction ID may be
determined by looking for the largest file name in
$PGDATA/pg_clog, adding one, and then multiplying by
1048576. Note that the file names are in hexadecimal. It
is usually easiest to specify the switch value in hexadec-
imal too. For example, if 0011 is the largest entry in
pg_clog, -x 0x1200000 will work (five trailing zeroes pro-
vide the proper multiplier). The WAL starting address
should be larger than any file number currently existing
in $PGDATA/pg_xlog. These also are in hex, and have two
parts. For example, if 000000FF0000003A is the largest
entry in pg_xlog, -l 0xFF,0x3B will work. There is no
comparably easy way to determine a next OID that's beyond
the largest one in the database, but fortunately it is not
critical to get the next-OID setting right.
The -n (no operation) switch instructs pg_resetxlog to
print the values reconstructed from pg_control and then
exit without modifying anything. This is mainly a debug-
ging tool, but may be useful as a sanity check before
allowing pg_resetxlog to proceed for real.
NOTES
This command must not be used when the postmaster is run-
ning. pg_resetxlog will refuse to start up if it finds a
postmaster lock file in the datadir. If the postmaster
crashed then a lock file may have been left behind; in
that case you can remove the lock file to allow
pg_resetxlog to run. But before you do so, make doubly
certain that there is no postmaster nor any backend server
process still alive.
Application 2002-11-22 PG_RESETXLOG(1)
