opendbteam workspace

opendbteam workspace
opendbteam workspace

Thursday, October 27, 2016

#PostgreSQL #9.6.1, #9.5.5, #9.4.10, #9.3.15, #9.2.19 and #9.1.24 #Released!



There is a new update for each version of PostgreSQL database system (9.6.1, 9.5.5, 9.4.10, 9.3.15, 9.2.19, and 9.1.24). The 9.1 update is also the last seeing as it is now end-of-life. 
Other than the typical small bug fixes, this release fixes two instances of data corruption (see below).
Apply this update at the next possible downtime.


WAL-logging of truncated relations
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
If checksumming is enabled, checksum failures in the visibility map could also occur.

This issue is present in the 9.3, 9.4, 9.5, and 9.6 series of PostgreSQL releases.


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. Please read the "Updating" section for post-installation instructions on how to resolve this issue on your PostgreSQL instances.

This issue is present only in the PostgreSQL 9.6.0 release.

No comments:

Post a Comment