Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages

  
 
  

home | help
PG_RESETXLOG(1)		PostgreSQL 9.6.19 Documentation	       PG_RESETXLOG(1)

NAME
       pg_resetxlog - reset the	write-ahead log	and other control information
       of a PostgreSQL database	cluster

SYNOPSIS
       pg_resetxlog [-f] [-n] [option...] {[-D]	datadir}

DESCRIPTION
       pg_resetxlog clears the write-ahead log (WAL) and optionally resets
       some other control information stored 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 might	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 data directory. 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) option. In this case plausible values will be substituted for
       the missing data. Most of the fields can	be expected to match, but
       manual assistance might be needed for the next OID, next	transaction ID
       and epoch, next multitransaction	ID and offset, and WAL starting
       address fields. These fields can	be set using the options discussed
       below. 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.

OPTIONS
       -f
	   Force pg_resetxlog to proceed even if it cannot determine valid
	   data	for pg_control,	as explained above.

       -n
	   The -n (no operation) option	instructs pg_resetxlog to print	the
	   values reconstructed	from pg_control	and values about to be
	   changed, and	then exit without modifying anything. This is mainly a
	   debugging tool, but can be useful as	a sanity check before allowing
	   pg_resetxlog	to proceed for real.

       -V
       --version
	   Display version information,	then exit.

       -?
       --help
	   Show	help, then exit.

       The following options are only needed when pg_resetxlog is unable to
       determine appropriate values by reading pg_control. Safe	values can be
       determined as described below. For values that take numeric arguments,
       hexadecimal values can be specified by using the	prefix 0x.

       -c xid,xid
	   Manually set	the oldest and newest transaction IDs for which	the
	   commit time can be retrieved.

	   A safe value	for the	oldest transaction ID for which	the commit
	   time	can be retrieved (first	part) can be determined	by looking for
	   the numerically smallest file name in the directory pg_commit_ts
	   under the data directory. Conversely, a safe	value for the newest
	   transaction ID for which the	commit time can	be retrieved (second
	   part) can be	determined by looking for the numerically greatest
	   file	name in	the same directory. The	file names are in hexadecimal.

       -e xid_epoch
	   Manually set	the next transaction ID's epoch.

	   The transaction ID epoch is not actually stored anywhere in the
	   database except in the field	that is	set by pg_resetxlog, so	any
	   value will work so far as the database itself is concerned. You
	   might need to adjust	this value to ensure that replication systems
	   such	as Slony-I and Skytools	work correctly -- if so, an
	   appropriate value should be obtainable from the state of the
	   downstream replicated database.

       -l xlogfile
	   Manually set	the WAL	starting address.

	   The WAL starting address should be larger than any WAL segment file
	   name	currently existing in the directory pg_xlog under the data
	   directory. These names are also in hexadecimal and have three
	   parts. The first part is the	"timeline ID" and should usually be
	   kept	the same. For example, if 00000001000000320000004A is the
	   largest entry in pg_xlog, use -l 00000001000000320000004B or
	   higher.

	       Note
	       pg_resetxlog itself looks at the	files in pg_xlog and chooses a
	       default -l setting beyond the last existing file	name.
	       Therefore, manual adjustment of -l should only be needed	if you
	       are aware of WAL	segment	files that are not currently present
	       in pg_xlog, such	as entries in an offline archive; or if	the
	       contents	of pg_xlog have	been lost entirely.

       -m mxid,mxid
	   Manually set	the next and oldest multitransaction ID.

	   A safe value	for the	next multitransaction ID (first	part) can be
	   determined by looking for the numerically largest file name in the
	   directory pg_multixact/offsets under	the data directory, adding
	   one,	and then multiplying by	65536 (0x10000). Conversely, a safe
	   value for the oldest	multitransaction ID (second part of -m)	can be
	   determined by looking for the numerically smallest file name	in the
	   same	directory and multiplying by 65536. The	file names are in
	   hexadecimal,	so the easiest way to do this is to specify the	option
	   value in hexadecimal	and append four	zeroes.

       -o oid
	   Manually set	the next OID.

	   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.

       -O mxoff
	   Manually set	the next multitransaction offset.

	   A safe value	can be determined by looking for the numerically
	   largest file	name in	the directory pg_multixact/members under the
	   data	directory, adding one, and then	multiplying by 52352 (0xCC80).
	   The file names are in hexadecimal. There is no simple recipe	such
	   as the ones for other options of appending zeroes.

       -x xid
	   Manually set	the next transaction ID.

	   A safe value	can be determined by looking for the numerically
	   largest file	name in	the directory pg_clog 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
	   0011	is the largest entry in	pg_clog, -x 0x1200000 will work	(five
	   trailing zeroes provide the proper multiplier).

NOTES
       This command must not be	used when the server is	running.  pg_resetxlog
       will refuse to start up if it finds a server lock file in the data
       directory. If the server	crashed	then a lock file might 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
       server process still alive.

       pg_resetxlog works only with servers of the same	major version.

SEE ALSO
       pg_controldata(1)

PostgreSQL 9.6.19		     2020		       PG_RESETXLOG(1)

NAME | SYNOPSIS | DESCRIPTION | OPTIONS | NOTES | SEE ALSO

Want to link to this manual page? Use this URL:
<https://www.freebsd.org/cgi/man.cgi?query=pg_resetxlog&sektion=1&manpath=FreeBSD+12.1-RELEASE+and+Ports>

home | help