From e19e4cf0be2892d3c894d6e37b905024f5977ab2 Mon Sep 17 00:00:00 2001 From: Peter Eisentraut Date: Mon, 29 Feb 2016 18:48:34 -0500 Subject: [PATCH] doc: Reorganize pg_resetxlog reference page The pg_resetxlog reference page didn't have a proper options list, only running text listing the options and some explanations of them. This might have worked when there were only a few options, but the list has grown over the releases, and now it's hard to find an option and its associated explanation. So write out the options list as on other reference pages. --- doc/src/sgml/ref/pg_resetxlog.sgml | 236 ++++++++++++++++++----------- 1 file changed, 151 insertions(+), 85 deletions(-) diff --git a/doc/src/sgml/ref/pg_resetxlog.sgml b/doc/src/sgml/ref/pg_resetxlog.sgml index 1bcc5a7ff03..fd9d0be6f44 100644 --- a/doc/src/sgml/ref/pg_resetxlog.sgml +++ b/doc/src/sgml/ref/pg_resetxlog.sgml @@ -22,15 +22,9 @@ PostgreSQL documentation pg_resetxlog - xid,xid - oid - xid - xid_epoch - mxid,mxid - mxoff - xlogfile + option datadir @@ -76,78 +70,108 @@ PostgreSQL documentation execute any data-modifying operations in the database before you dump, as any such action is likely to make the corruption worse. + + + + Options + + + + + + + Force pg_resetxlog to proceed even if it cannot determine + valid data for pg_control, as explained above. + + + + + + + + + The + + + + + + + Display version information, then exit. + + + + + + Show help, then exit. + + - The - + + + xid,xid - A safe value for the next transaction ID ( - - - - A safe value for the next multitransaction ID (first part of - - - - - A safe value for the next multitransaction offset ( - - - A safe value for the oldest transaction ID for which the commit time can - be retrieved (first part of + + + xid_epoch - The WAL starting address ( + + + 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. + + + + + + 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 @@ -168,46 +192,81 @@ PostgreSQL documentation + + + 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 + + + + + + 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. + + + mxoff - 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. + 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. - - + - - The - - - The + + 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). + + + + @@ -224,4 +283,11 @@ PostgreSQL documentation + + See Also + + + + +