Incorporated changes from -hackers for cumulative 2016-10-27 release

diff --git a/update_releases/current/update_201610.md b/update_releases/current/update_201610.md
index aac4d0b36f3f3017d319ac617eff901efe0c10c0..11c9fb9504add6b5c060763722aba1cd2eb4afd4 100644 (file)
--- a/update_releases/current/update_201610.md
+++ b/update_releases/current/update_201610.md
@@ -6,7 +6,7 @@ The PostgreSQL Global Development Group has released an update to all supported
 WAL-logging of truncated relations
 ----------------------------------
 
-Prior to this release, there was a chance that a PostgreSQL instance in recovery would try to access data that no longer existed on disk.  If the free space map was not updated to be aware of the truncation, a PostgreSQL database in recovery mode could return a page that was already truncated and produce an error such as:
+Prior to this release, there was a chance that a PostgreSQL instance would try to access data that no longer existed on disk.  If the free space map was not updated to be aware of the truncation, a PostgreSQL database could return a page that was already truncated and produce an error such as:
 
     ERROR:  could not read block 28991 in file "base/16390/572026": read only 0 of 8192 bytes
 
@@ -19,10 +19,9 @@ pg_upgrade issues on big-endian machines
 
 On big-endian machines (e.g. many non-Intel CPU architectures), pg_upgrade would incorrectly write the bytes of the visibility map leading to pg_upgrade failing to complete.
 
-If you are using a big-endian machine (many non-Intel architectures are big-endian) and have used pg_upgrade to upgrade from a pre-9.6 release, you should assume that all visibility maps are incorrect and need to be regenerated. It is sufficient to truncate each relation's visibility map with contrib/pg_visibility's pg_truncate_visibility_map() function.  As a PostgreSQL superuser, you can run the following:
+If you are using a big-endian machine (many non-Intel architectures are big-endian) and have used pg_upgrade to upgrade from a pre-9.6 release, you should assume that all visibility maps are incorrect and need to be regenerated. It is sufficient to truncate each relation's visibility map with contrib/pg_visibility's pg_truncate_visibility_map() function.  Please read the "Updating" section for post-installation instructions on how to resolve this issue on your PostgreSQL instances.
 
-    CREATE EXTENSION pg_visibility;
-    SELECT pg_truncate_visibility_map();
+This issue is present only in the PostgreSQL 9.6.0 release.
 
 Bug Fixes and Improvements
 --------------------------
@@ -69,10 +68,7 @@ Updating
 
 All PostgreSQL update releases are cumulative. As with other minor releases, users are not required to dump and reload their database or use pg_upgrade in order to apply this update release; you may simply shut down PostgreSQL and update its binaries.
 
-If your system was affected by the big-endian pg_upgrade bug, you will have to run the following as a PostgreSQL superuser:
-
-    CREATE EXTENSION pg_visibility;
-    SELECT pg_truncate_visibility_map();
+If your system was affected by the big-endian pg_upgrade bug, please read [Visibility Map Problems](https://wiki.postgresql.org/wiki/Visibility_Map_Problems) and follow the instructions on how to fix your this issue on your PostgreSQL instances.
 
 Users who have skipped one or more update releases may need to run additional, post-update steps; please see the release notes for earlier versions for details.