doc: ALTER DEFAULT PRIVILEGES does not affect inherited roles
[pgsql.git] / doc / src / sgml / ref / pg_resetwal.sgml
blob08cd3ce5fc20a8e0a05e0b426588e221ef5a57a1
1 <!--
2 doc/src/sgml/ref/pg_resetwal.sgml
3 PostgreSQL documentation
4 -->
6 <refentry id="app-pgresetwal">
7 <indexterm zone="app-pgresetwal">
8 <primary>pg_resetwal</primary>
9 </indexterm>
11 <refmeta>
12 <refentrytitle><application>pg_resetwal</application></refentrytitle>
13 <manvolnum>1</manvolnum>
14 <refmiscinfo>Application</refmiscinfo>
15 </refmeta>
17 <refnamediv>
18 <refname>pg_resetwal</refname>
19 <refpurpose>reset the write-ahead log and other control information of a <productname>PostgreSQL</productname> database cluster</refpurpose>
20 </refnamediv>
22 <refsynopsisdiv>
23 <cmdsynopsis>
24 <command>pg_resetwal</command>
25 <group choice="opt">
26 <arg choice="plain"><option>-f</option></arg>
27 <arg choice="plain"><option>--force</option></arg>
28 </group>
29 <group choice="opt">
30 <arg choice="plain"><option>-n</option></arg>
31 <arg choice="plain"><option>--dry-run</option></arg>
32 </group>
33 <arg rep="repeat"><replaceable>option</replaceable></arg>
34 <group choice="plain">
35 <group choice="opt">
36 <arg choice="plain"><option>-D</option></arg>
37 <arg choice="plain"><option>--pgdata</option></arg>
38 </group>
39 <replaceable class="parameter">datadir</replaceable>
40 </group>
41 </cmdsynopsis>
42 </refsynopsisdiv>
44 <refsect1 id="r1-app-pgresetwal-1">
45 <title>Description</title>
46 <para>
47 <command>pg_resetwal</command> clears the write-ahead log (WAL) and
48 optionally resets some other control information stored in the
49 <filename>pg_control</filename> file. This function is sometimes needed
50 if these files have become corrupted. It should be used only as a
51 last resort, when the server will not start due to such corruption.
52 </para>
54 <para>
55 Some options, such as <option>--wal-segsize</option> (see below), can also
56 be used to modify certain global settings of a database cluster without the
57 need to rerun <command>initdb</command>. This can be done safely on an
58 otherwise sound database cluster, if none of the dangerous modes mentioned
59 below are used.
60 </para>
62 <para>
63 If <command>pg_resetwal</command> is used on a data directory where the
64 server has been cleanly shut down and the control file is sound, then it
65 will have no effect on the contents of the database system, except that no
66 longer used WAL files are cleared away. Any other use is potentially
67 dangerous and must be done with great care. <command>pg_resetwal</command>
68 will require the <option>-f</option> (force) option to be specified before
69 working on a data directory in an unclean shutdown state or with a
70 corrupted control file.
71 </para>
73 <para>
74 After running this command on a data directory with corrupted WAL or a
75 corrupted control file, it should be possible to start the server,
76 but bear in mind that the database might contain inconsistent data due to
77 partially-committed transactions. You should immediately dump your data,
78 run <command>initdb</command>, and restore. After restore, check for
79 inconsistencies and repair as needed.
80 </para>
82 <para>
83 If <command>pg_resetwal</command> complains that it cannot determine
84 valid data for <filename>pg_control</filename>, you can force it to proceed anyway
85 by specifying the <option>-f</option> (force) option. In this case plausible
86 values will be substituted for the missing data. Most of the fields can be
87 expected to match, but manual assistance might be needed for the next OID,
88 next transaction ID and epoch, next multitransaction ID and offset, and
89 WAL starting location fields. These fields can be set using the options
90 discussed below. If you are not able to determine correct values for all
91 these fields, <option>-f</option> can still be used, but
92 the recovered database must be treated with even more suspicion than
93 usual: an immediate dump and restore is imperative. <emphasis>Do not</emphasis>
94 execute any data-modifying operations in the database before you dump,
95 as any such action is likely to make the corruption worse.
96 </para>
98 <para>
99 This utility can only be run by the user who installed the server, because
100 it requires read/write access to the data directory.
101 </para>
102 </refsect1>
104 <refsect1>
105 <title>Options</title>
107 <variablelist>
108 <varlistentry>
109 <term><replaceable class="parameter">datadir</replaceable></term>
110 <term><option>-D <replaceable class="parameter">datadir</replaceable></option></term>
111 <term><option>--pgdata=<replaceable class="parameter">datadir</replaceable></option></term>
112 <listitem>
113 <para>
114 Specifies the location of the database directory.
115 For safety reasons, you must specify the data directory on the command
116 line. <command>pg_resetwal</command> does not use the environment
117 variable <envar>PGDATA</envar>.
118 </para>
119 </listitem>
120 </varlistentry>
122 <varlistentry>
123 <term><option>-f</option></term>
124 <term><option>--force</option></term>
125 <listitem>
126 <para>
127 Force <command>pg_resetwal</command> to proceed even in situations where
128 it could be dangerous, as explained above. Specifically, this option is
129 required to proceed if the server had not been cleanly shut down or if
130 <command>pg_resetwal</command> cannot determine valid data for
131 <filename>pg_control</filename>.
132 </para>
133 </listitem>
134 </varlistentry>
136 <varlistentry>
137 <term><option>-n</option></term>
138 <term><option>--dry-run</option></term>
139 <listitem>
140 <para>
141 The <option>-n</option>/<option>--dry-run</option> option instructs
142 <command>pg_resetwal</command> to print the values reconstructed from
143 <filename>pg_control</filename> and values about to be changed, and then exit
144 without modifying anything. This is mainly a debugging tool, but can be
145 useful as a sanity check before allowing <command>pg_resetwal</command>
146 to proceed for real.
147 </para>
148 </listitem>
149 </varlistentry>
151 <varlistentry>
152 <term><option>-V</option></term>
153 <term><option>--version</option></term>
154 <listitem><para>Display version information, then exit.</para></listitem>
155 </varlistentry>
157 <varlistentry>
158 <term><option>-?</option></term>
159 <term><option>--help</option></term>
160 <listitem><para>Show help, then exit.</para></listitem>
161 </varlistentry>
162 </variablelist>
164 <para>
165 The following options are only needed when
166 <command>pg_resetwal</command> is unable to determine appropriate values
167 by reading <filename>pg_control</filename>. Safe values can be determined as
168 described below. For values that take numeric arguments, hexadecimal
169 values can be specified by using the prefix <literal>0x</literal>.
170 </para>
172 <variablelist>
173 <varlistentry>
174 <term><option>-c <replaceable class="parameter">xid</replaceable>,<replaceable class="parameter">xid</replaceable></option></term>
175 <term><option>--commit-timestamp-ids=<replaceable class="parameter">xid</replaceable>,<replaceable class="parameter">xid</replaceable></option></term>
176 <listitem>
177 <para>
178 Manually set the oldest and newest transaction IDs for which the commit
179 time can be retrieved.
180 </para>
182 <para>
183 A safe value for the oldest transaction ID for which the commit time can
184 be retrieved (first part) can be determined by looking
185 for the numerically smallest file name in the directory
186 <filename>pg_commit_ts</filename> under the data directory. Conversely, a safe
187 value for the newest transaction ID for which the commit time can be
188 retrieved (second part) can be determined by looking for the numerically
189 greatest file name in the same directory. The file names are in
190 hexadecimal.
191 </para>
192 </listitem>
193 </varlistentry>
195 <varlistentry>
196 <term><option>-e <replaceable class="parameter">xid_epoch</replaceable></option></term>
197 <term><option>--epoch=<replaceable class="parameter">xid_epoch</replaceable></option></term>
198 <listitem>
199 <para>
200 Manually set the next transaction ID's epoch.
201 </para>
203 <para>
204 The transaction ID epoch is not actually stored anywhere in the database
205 except in the field that is set by <command>pg_resetwal</command>,
206 so any value will work so far as the database itself is concerned.
207 You might need to adjust this value to ensure that replication
208 systems such as <application>Slony-I</application> and
209 <application>Skytools</application> work correctly &mdash;
210 if so, an appropriate value should be obtainable from the state of
211 the downstream replicated database.
212 </para>
213 </listitem>
214 </varlistentry>
216 <varlistentry>
217 <term><option>-l <replaceable class="parameter">walfile</replaceable></option></term>
218 <term><option>--next-wal-file=<replaceable class="parameter">walfile</replaceable></option></term>
219 <listitem>
220 <para>
221 Manually set the WAL starting location by specifying the name of the
222 next WAL segment file.
223 </para>
225 <para>
226 The name of next WAL segment file should be
227 larger than any WAL segment file name currently existing in
228 the directory <filename>pg_wal</filename> under the data directory.
229 These names are also in hexadecimal and have three parts. The first
230 part is the <quote>timeline ID</quote> and should usually be kept the same.
231 For example, if <filename>00000001000000320000004A</filename> is the
232 largest entry in <filename>pg_wal</filename>, use <literal>-l 00000001000000320000004B</literal> or higher.
233 </para>
235 <para>
236 Note that when using nondefault WAL segment sizes, the numbers in the WAL
237 file names are different from the LSNs that are reported by system
238 functions and system views. This option takes a WAL file name, not an
239 LSN.
240 </para>
242 <note>
243 <para>
244 <command>pg_resetwal</command> itself looks at the files in
245 <filename>pg_wal</filename> and chooses a default <option>-l</option> setting
246 beyond the last existing file name. Therefore, manual adjustment of
247 <option>-l</option> should only be needed if you are aware of WAL segment
248 files that are not currently present in <filename>pg_wal</filename>, such as
249 entries in an offline archive; or if the contents of
250 <filename>pg_wal</filename> have been lost entirely.
251 </para>
252 </note>
253 </listitem>
254 </varlistentry>
256 <varlistentry>
257 <term><option>-m <replaceable class="parameter">mxid</replaceable>,<replaceable class="parameter">mxid</replaceable></option></term>
258 <term><option>--multixact-ids=<replaceable class="parameter">mxid</replaceable>,<replaceable class="parameter">mxid</replaceable></option></term>
259 <listitem>
260 <para>
261 Manually set the next and oldest multitransaction ID.
262 </para>
264 <para>
265 A safe value for the next multitransaction ID (first part) can be
266 determined by looking for the numerically largest file name in the
267 directory <filename>pg_multixact/offsets</filename> under the data directory,
268 adding one, and then multiplying by 65536 (0x10000). Conversely, a safe
269 value for the oldest multitransaction ID (second part of
270 <option>-m</option>) can be determined by looking for the numerically smallest
271 file name in the same directory and multiplying by 65536. The file
272 names are in hexadecimal, so the easiest way to do this is to specify
273 the option value in hexadecimal and append four zeroes.
274 </para>
275 </listitem>
276 </varlistentry>
278 <varlistentry>
279 <term><option>-o <replaceable class="parameter">oid</replaceable></option></term>
280 <term><option>--next-oid=<replaceable class="parameter">oid</replaceable></option></term>
281 <listitem>
282 <para>
283 Manually set the next OID.
284 </para>
286 <para>
287 There is no comparably easy way to determine a next OID that's beyond
288 the largest one in the database, but fortunately it is not critical to
289 get the next-OID setting right.
290 </para>
291 </listitem>
292 </varlistentry>
294 <varlistentry>
295 <term><option>-O <replaceable class="parameter">mxoff</replaceable></option></term>
296 <term><option>--multixact-offset=<replaceable class="parameter">mxoff</replaceable></option></term>
297 <listitem>
298 <para>
299 Manually set the next multitransaction offset.
300 </para>
302 <para>
303 A safe value can be determined by looking for the numerically largest
304 file name in the directory <filename>pg_multixact/members</filename> under the
305 data directory, adding one, and then multiplying by 52352 (0xCC80).
306 The file names are in hexadecimal. There is no simple recipe such as
307 the ones for other options of appending zeroes.
308 </para>
309 </listitem>
310 </varlistentry>
312 <varlistentry>
313 <term><option>--wal-segsize=<replaceable class="parameter">wal_segment_size</replaceable></option></term>
314 <listitem>
315 <para>
316 Set the new WAL segment size, in megabytes. The value must be set to a
317 power of 2 between 1 and 1024 (megabytes). See the same option of <xref
318 linkend="app-initdb"/> for more information.
319 </para>
321 <para>
322 This option can also be used to change the WAL segment size of an
323 existing database cluster, avoiding the need to
324 re-<command>initdb</command>.
325 </para>
327 <note>
328 <para>
329 While <command>pg_resetwal</command> will set the WAL starting address
330 beyond the latest existing WAL segment file, some segment size changes
331 can cause previous WAL file names to be reused. It is recommended to
332 use <option>-l</option> together with this option to manually set the
333 WAL starting address if WAL file name overlap will cause problems with
334 your archiving strategy.
335 </para>
336 </note>
337 </listitem>
338 </varlistentry>
340 <varlistentry>
341 <term><option>-u <replaceable class="parameter">xid</replaceable></option></term>
342 <term><option>--oldest-transaction-id=<replaceable class="parameter">xid</replaceable></option></term>
343 <listitem>
344 <para>
345 Manually set the oldest unfrozen transaction ID.
346 </para>
348 <para>
349 A safe value can be determined by looking for the numerically smallest
350 file name in the directory <filename>pg_xact</filename> under the data directory
351 and then multiplying by 1048576 (0x100000). Note that the file names are in
352 hexadecimal. It is usually easiest to specify the option value in
353 hexadecimal too. For example, if <filename>0007</filename> is the smallest entry
354 in <filename>pg_xact</filename>, <literal>-u 0x700000</literal> will work (five
355 trailing zeroes provide the proper multiplier).
356 </para>
357 </listitem>
358 </varlistentry>
360 <varlistentry>
361 <term><option>-x <replaceable class="parameter">xid</replaceable></option></term>
362 <term><option>--next-transaction-id=<replaceable class="parameter">xid</replaceable></option></term>
363 <listitem>
364 <para>
365 Manually set the next transaction ID.
366 </para>
368 <para>
369 A safe value can be determined by looking for the numerically largest
370 file name in the directory <filename>pg_xact</filename> under the data directory,
371 adding one,
372 and then multiplying by 1048576 (0x100000). Note that the file names are in
373 hexadecimal. It is usually easiest to specify the option value in
374 hexadecimal too. For example, if <filename>0011</filename> is the largest entry
375 in <filename>pg_xact</filename>, <literal>-x 0x1200000</literal> will work (five
376 trailing zeroes provide the proper multiplier).
377 </para>
378 </listitem>
379 </varlistentry>
380 </variablelist>
381 </refsect1>
383 <refsect1>
384 <title>Environment</title>
386 <variablelist>
387 <varlistentry>
388 <term><envar>PG_COLOR</envar></term>
389 <listitem>
390 <para>
391 Specifies whether to use color in diagnostic messages. Possible values
392 are <literal>always</literal>, <literal>auto</literal> and
393 <literal>never</literal>.
394 </para>
395 </listitem>
396 </varlistentry>
397 </variablelist>
398 </refsect1>
400 <refsect1>
401 <title>Notes</title>
403 <para>
404 This command must not be used when the server is
405 running. <command>pg_resetwal</command> will refuse to start up if
406 it finds a server lock file in the data directory. If the
407 server crashed then a lock file might have been left
408 behind; in that case you can remove the lock file to allow
409 <command>pg_resetwal</command> to run. But before you do
410 so, make doubly certain that there is no server process still alive.
411 </para>
413 <para>
414 <command>pg_resetwal</command> works only with servers of the same
415 major version.
416 </para>
417 </refsect1>
419 <refsect1>
420 <title>See Also</title>
422 <simplelist type="inline">
423 <member><xref linkend="app-pgcontroldata"/></member>
424 </simplelist>
425 </refsect1>
426 </refentry>