From 387f3e441666ce4d2a1e5f4e52247ce3a83e733d Mon Sep 17 00:00:00 2001 From: "Jonathan S. Katz" Date: Mon, 24 Oct 2016 16:49:32 -0400 Subject: [PATCH] Incorporated changes from -hackers for cumulative 2016-10-27 release --- update_releases/current/update_201610.md | 12 ++++-------- 1 file changed, 4 insertions(+), 8 deletions(-) diff --git a/update_releases/current/update_201610.md b/update_releases/current/update_201610.md index aac4d0b..11c9fb9 100644 --- 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. -- 2.39.5