The PostgreSQL Global Development Group has released an update to all supported versions of our database system, including 11.2, 10.7, 9.6.12, 9.5.16, and 9.4.21. This release changes the behavior in how PostgreSQL interfaces with fsync()
and includes fixes for partitioning and over 70 other bugs that were reported over the past three months.
Users should plan to apply this update at the next scheduled downtime.
When available in an operating system and enabled in the configuration file (which it is by default), PostgreSQL uses the kernel function fsync()
to help ensure that data is written to a disk. In some operating systems that provide fsync()
, when the kernel is unable to write out the data, it returns a failure and flushes the data that was supposed to be written from its data buffers.
This flushing operation has an unfortunate side-effect for PostgreSQL: if PostgreSQL tries again to write the data to disk by again calling fsync()
, fsync()
will report back that it succeeded, but the data that PostgreSQL believed to be saved to the disk would not actually be written. This presents a possible data corruption scenario.
This update modifies how PostgreSQL handles a fsync()
failure: PostgreSQL will no longer retry calling fsync()
but instead will panic. In this case, PostgreSQL can then replay the data from the write-ahead log (WAL) to help ensure the data is written. While this may appear to be a suboptimal solution, there are presently few alternatives and, based on reports, the problem case occurs extremely rarely.
A new server parameter data_sync_retry
has been added to manage this behavior. If you are certain that your kernel does not discard dirty data buffers in such scenarios, you can set data_sync_retry
to on
to restore the old behavior.
This update introduces a change into how release notes are packaged. As of this update, all currently supported versions of PostgreSQL will only contain their major version-specific release notes. For example, PostgreSQL 11 only packages the release notes for version 11.2, 11.1, and 11.0. The release notes for unsupported versions (PostgreSQL 9.3 and older) will be available in older releases and from a soon-to-be released archive on the PostgreSQL website.
This update also fixes over 70 bugs that were reported in the last several months. Some of these issues affect only version 11, but many affect all supported versions.
Some of these fixes include:
INCLUDE
columns on partitioned tablesNOT NULL
constraints of a partitioned table are honored within its partitionsON COMMIT DROP
and ON COMMIT DELETE ROWS
to partitioned tables and tables with inheritance childrenCOPY FREEZE
on partitioned tablesALTER TABLE .. ADD COLUMN
with a non-nullable default feature, including a possible index corruption caseUPDATE
with a multiple SET
clause using a sub-SELECT
json[b]_populate_recordset()
or json[b]_to_recordset()
CALL
statementTRUNCATE
ALTER TABLE ONLY ADD COLUMN IF NOT EXISTS
is processed correctlyUNLISTEN
in hot-standby (replica) modepg_hba.conf
\g target
work with COPY TO STDOUT
pgbench
is now fully deterministic and platform-independent when --random-seed=N
is specifiedpg_basebackup
and pg_verify_checksums
to appropriately ignore temporary filespg_dump
, including having ALTER INDEX SET STATISTICS
commands presentThis update also contains tzdata release 2018i for DST law changes in Kazakhstan, Metlakatla, and Sao Tome and Principe. Kazakhstan's Qyzylorda zone is split in two, creating a new zone Asia/Qostanay, as some areas did not change UTC offset. Historical corrections for Hong Kong and numerous Pacific islands.
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 shutdown PostgreSQL and update its binaries.
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.
PostgreSQL 9.4 will stop receiving fixes on February 13, 2020. Please see our versioning policy for more information.