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 + + + + +