postgresql/contrib/pg_resetxlog
Tom Lane 7d4d5c00f0 Arrange to recycle old XLOG log segment files as new segment files,
rather than deleting them only to have to create more.  Steady state
is 2*CHECKPOINT_SEGMENTS + WAL_FILES + 1 segment files, which will
simply be renamed rather than constantly deleted and recreated.
To make this safe, added current XLOG file/offset number to page
header of XLOG pages, so that an un-overwritten page from an old
incarnation of a logfile can be reliably told from a valid page.
This change means that if you try to restart postmaster in a CVS-tip
database after installing the change, you'll get a complaint about
bad XLOG page magic number.  If you don't want to initdb, run
contrib/pg_resetxlog (and be sure you shut down the old postmaster
cleanly).
2001-07-19 02:12:35 +00:00
..
Makefile Provide snprintf() if system hasn't got it. 2001-04-03 19:06:19 +00:00
README.pg_resetxlog First cut at XLOG file reset utility. 2001-03-14 00:57:43 +00:00
pg_resetxlog.c Arrange to recycle old XLOG log segment files as new segment files, 2001-07-19 02:12:35 +00:00

README.pg_resetxlog

pg_resetxlog is a program to clear the WAL transaction log (stored in
$PGDATA/pg_xlog/), replacing whatever had been in it with just a dummy
shutdown-checkpoint record.  It also regenerates the pg_control file
if necessary.

THIS PROGRAM WILL DESTROY VALUABLE LOG DATA!!!  Don't run it unless you
really need it!!!

pg_resetxlog is primarily intended for disaster recovery --- that is,
if your pg_control and/or xlog are hosed badly enough that Postgres refuses
to start up, this program will get you past that problem and let you get to
your data files.  But realize that without the xlog, your data files may be
corrupt due to partially-applied transactions, incomplete index-file
updates, etc.  You should dump your data, check it for accuracy, then initdb
and reload.

A secondary purpose is to cope with xlog format changes without requiring
initdb.  To use pg_resetxlog for this purpose, just be sure that you have
cleanly shut down your old postmaster (if you're not sure, see the contrib
module pg_controldata and run it to be sure the DB state is SHUTDOWN).
Then run pg_resetxlog, and finally install and start the new version of
the database software.

To run the program, make sure your postmaster is not running, then
(as the Postgres admin user) do

	pg_resetxlog $PGDATA

As a safety measure, the target data directory must be specified on the
command line, it cannot be defaulted.

If pg_resetxlog complains that it can't reconstruct valid data for pg_control,
you can force it to invent plausible data values with

	pg_resetxlog -f $PGDATA

If this turns out to be necessary then you *definitely* should plan on
immediate dump, initdb, reload --- any modifications you do to the database
after "pg_resetxlog -f" would be likely to corrupt things even worse.