@@ -6059,15 +6059,17 @@ LOG: CleanUpLock: deleting: lock(0xb7acd844) id(24688,24696,0,0,0,1)
60596059 <para>
60606060 Detection of a damaged page header normally causes
60616061 <productname>PostgreSQL</> to report an error, aborting the current
6062- command . Setting <varname>zero_damaged_pages</> to on causes
6063- the system to instead report a warning, zero out the damaged page,
6064- and continue processing. This behavior <emphasis>will destroy data</>,
6065- namely all the rows on the damaged page.But itallows you to get
6062+ transaction . Setting <varname>zero_damaged_pages</> to on causes
6063+ the system to instead report a warning, zero out the damaged
6064+ page in memory, and continue processing. This behavior <emphasis>will destroy data</>,
6065+ namely all the rows on the damaged page.However, itdoes allow you to get
60666066 past the error and retrieve rows from any undamaged pages that might
6067- be present in the table.So it is useful for recovering data if
6067+ be present in the table.It is useful for recovering data if
60686068 corruption has occurred due to a hardware or software error. You should
60696069 generally not set this on until you have given up hope of recovering
6070- data from the damaged pages of a table. The
6070+ data from the damaged pages of a table. Zerod-out pages are not
6071+ forced to disk so it is recommended to recreate the table or
6072+ the index before turning this parameter off again. The
60716073 default setting is <literal>off</>, and it can only be changed
60726074 by a superuser.
60736075 </para>